Re: glibc 2.2 and gcc (Was Re: something completely different)
On Thu, Aug 03, 2000 at 05:41:32PM -0400, Christopher C. Chimelis wrote:
>
> On Thu, 3 Aug 2000, Ben Collins wrote:
>
> > > I assume it identifies as libc6.2. Then it will build with another
> > > soname. However I would like to have something like a staging area for
> > > glibc, binutils and libstdc++, before an upload is done. Currently I
> > > don't know of any incompatibilities between 2.1 and 2.2, which should
> > > affect libstdc++ ...
> >
> > My limited tests on sparc, i386 and powerpc show no incompatibilites. I do
> > agree with a staging area, and that was my next suggestion. Problem is,
> > how do we stage for this to keep all C++ applications from breaking? Will
> > we need a libstdc++2.10-glibc2.1 like with the 2.0->2.1 upgrade had, and
> > if so, what will I need to do to enable this?
> >
> > I've Cc'd alpha list to ask about the package name currently involved
> > (libc6.1) will that need to change to 6.2? What about libc0.2 for hurd?
>
> If it identifies itself as libc6.2, then yes, the package name should
> change to libc6.2 (if this happens on all archs, we can FINALLY be inline
> with the rest of the archs).
Actually I'de rather get rid of that altogether. Makes upgrading horrible,
AFAICT. How would people cope with upgrades? libc6.2 would have to
conflict/replace libc6.1, and that doesn't sound like an ideal situation.
Given that 2.2 is pretty much binary compatible with things compiled on
2.1, I don't think changing the package name is needed (should only be so
if the soname changes, which would be expected if binary compatibility was
lost).
Can we take ths chance to make alpha more like everything else and
simply call it libc6? Obviously it's name will have to change anyway, and
that's a whole lot easier than changing it on all the other archs.
> I'm also concerned about the C++ application breakage, so keep me posted
> on this. As soon as potato is released, I'll upgrade my Alpha to woody
> and participate more, as per normal. If I understand correctly, we'll
> probably need a transition package like a libstdc++2.10-glibc2.2, FYI.
Right. Question is, how to do that. I'm not familiar with how it was done
before. IMO, this time we should work on doing everything we can to get
rid of it, really fast (binary only recompiles, etc..).
> Matthias, fyi, the last gcc snapshot that you packaged had bootstrap
> problems on alpha, so it wouldn't build. I'm going to check the latest
> CVS snapshot probably tomorrow and see if things build ok (I'm getting
> access to a dual-processor EV6, so the build should take much less time).
There are a lot of patches not merged into the main tree. Sparc64 compiler
wont build without them, and Matthias hasn't added them to the gcc-ss
package yet.
--
-----------=======-=-======-=========-----------=====------------=-=------
/ Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \
` bcollins@debian.org -- bcollins@openldap.org -- bcollins@linux.com '
`---=========------=======-------------=-=-----=-===-======-------=--=---'
Reply to: