This is the mail archive of the libc-alpha@sources.redhat.com mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Possible ld.so modifications


Well the issue isn't really one of elegance or efficiency (I wish it
was), it's more to do with if we build a package on one distro, and run
it on another, the program will have, ah, "undefined" behaviour, ie will
go crazy, hopefully segfault, worst case start corrupting data.

http://bugs.debian.org/cgi-bin/bugreport.cgi?archive=no&bug=136707

That links details the investigation Debian made into the matter, and
they seem to have arrived at the same conclusion - that the only
solution that could be used within a reasonable timeframe (ie the next
few years) would be to automatically version every symbol.

This doesn't increase efficiency but it does mean that if two versions
of the same lib are linked into an address space, the app will work, as
opposed to fail unpredictably (and possibly dangerously).

I'm googling for some compiler switches or something that will magically
version every symbol, but no luck so far. The debian bug refers to a
script that was written to generate headers that versioned symbols, but
it sounded like a nasty hack. Then, if all/all important libs are built
in this way, although it's not the best solution it does fix the issue
in the short term, and when upstream lib maintainers get the idea and
start using versioning it won't conflict.

On Tue, 2002-12-17 at 22:12, Roland McGrath wrote:
> If you want good versioning support, it requires cognizant effort on the
> part of the people who make the source code modifications that affect
> binary compatibility.  If you want to do anything wholly automatic without
> detailed information, such as a distribution could mechanically do en
> masse, then you can't do anything with symbol versioning that is materially
> better than bumping the soname for every release that might change any ABI
> in the slightest.  That is by far the simplest way to ensure that
> compatibility is never broken, it's just quite wasteful of space and of the
> resources to rebuild a lot of packages and users' time/bandwidth to install
> them.
-- 
Mike Hearn <mike@theoretic.com>


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]