Re: glibc 2.2 and gcc (Was Re: something completely different)
On Thu, 3 Aug 2000, Ben Collins wrote:
> 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).
Hmmm...well, changing Alpha's libc package name would involve the same
situation as if we all changed to libc6.2, at least on alpha. We'd have
to conflict/replace AND provide libc6.1 (to cope with older packages
and/or non-Debian-offered packages, such as the compilers that I helped to
package for Compaq). I don't think any of us would mind staying with
'libc6.1' on alpha since were so used to it, so if binary compatibility
isn't broken and we aren't changing the other archs' package name, then
let's stick to libc6.1 on alpha as well. The only time it really gives
problems for me is when dealing with hard-coded dependencies, which
shouldn't be around anymore anyway, IMO.
> 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 wish I had been of importance enough on Alpha when the libc6->libc6.1
change was made (I was still just getting started as a Debian
developer). I'm afraid it's a situation that we won't be able to change
easily until the soname does change for glibc.
> 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..).
Basically, we made the libstdc++ packages with the glibc version number so
that we could differentiate what'd been recompiled and what
hadn't. Luckily, libstdc++ changed sonames at the time, so it kinda took
care of itself after that, but if it hadn't, those packages would still be
there. I suppose we could do binary-only recompiles, which may make it
faster, but it would be harder to track across all archs than if we just
told all maintainers to upload new packages for recompilations to a
staging area that autobuilders don't look at until their libstdc++
packages are updated (we ran into this problem on Alpha before...had to
recompile ALOT of stuff as binary NMUs since the autobuilder hadn't been
updated, but was building the packages with "recompiled under new
libstdc++" in their changelogs).
> 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.
I'm building the latest snapshot now on Alpha. The problems that I noted
appear to have been fixed (from what I can tell) since the last gcc-ss
package was made.
C
Reply to: