Re: Glibc 2.1.94-3, fixes all issues with db libraries
On Sat, Sep 30, 2000 at 01:56:33PM -0400, Greg Stark wrote:
> Ben Collins <email@example.com> writes:
> > For those bitten by The Great Glibc Update of 2000, welcome to our annual
> > ritual. Please stay tuned during the next few months where we install a new
> > gcc. This will be followed by self inflicted pain of stricter C++ syntax,
> > macro collisions, binary incompatability and general chaos among kernel
> > builds. Thank you for your patronage, and please come again.
> It's still the case that binaries compiled on woody or RedHat 7 will crash
> randomly on potato or Redhat 6? If so in the current system that still
> requires changing the soname but of course that's a losing battle, right?
Backward compatible binaries are not guaranteed, I don't think. As for
soname, GLibc uses versioned symbols for a finer grain control of this. No
reason to change the soname if only two symbols change their ABI.
> Hmph, I wonder if ld.so/ld could be patched to have a list of sonames provided
> by a library for run-time but a single one to use for compile-time linking.
RH gets around this with a gross hack (IMHO) by making binaries depends on
library symbols as opposed to the library itself. Not something that is
very intuitive (do you have all the symbols of all the libraries ever
Debian gets around this by having strict dependencies on the packages.
That says nothing for straight binary compiles, but it works for package
installs. There's not much we can do about binary tarballs.
> That way glibc2.2 could provide sonames 2.0, 2.1, and 2.2 for run-time linking
> but when programs are compiled against it they would record 2.2 as the version
> they should be linked with.
> That seems like it would fix the binary incompatibility problems that glibc is
> introducing in linux recently.
Recently? :) It also doesn't help when the compiler breaks this aswell. We
do what we can without overcompilcating things.
/ Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \
` firstname.lastname@example.org -- email@example.com -- firstname.lastname@example.org '