Hello, On Tue, Mar 11, 2003 at 09:21:58AM +0100, Jakob Bohm wrote: > I have looked at -Bsymbolic, and it seems to be doing about the > same as my proposed change (see elsewhere), however the docs on this > potato box are too ambiguous to be usable, so here are some (stupid) > questions (don't bother to answer those) and some food for thought > depending on what the answers to the stupid questions are. I believe that <http://bugs.debian.org/136707> should be required reading for everyone involved in this thread. > 1. Is -Bsymbolic applied to the .so or the binary calling it? > (I assume the .so but it does not matter here). Normally, to the .so. > 2. If an .so is built with -Bsymbolic, can it still be used by > programs linked against a non-Bsymbolic copy of the same .so? Yes. > 3. If a binary is linked against a -Bsymbolic .so, can it still > be used with a non-Bsymbolic lib with the same .so name? Yes. > And finally the real question (I'll figure the above out myself, > but don't want to delay this message while I investigate): > 4. If the answers to both of the above are yes, what harm would > there be in simply turning -Bsymbolic on by default in the debian > copy of binutils (and contributing it upstream)? The harm is that interposition libraries that currently work (i.e., LD_PRELOAD'ing a library which overrides one or more symbols in a library which are in turn called by other functions in that same library which have not been overridden) will no longer work. Actually, the question you should be asking is: what is the gain if we use -Bsymbolic? As shown in #136707, the answer as regards the present problem is "not much", because -Bsymbolic only affects intra-object symbol resolution. There are a number of complex cases (increasingly common) that are not addressed by -Bsymbolic; and the only viable fix for those same cases (i.e., versioned symbols) renders -Bsymbolic unnecessary. See bug #184509 for another real-world bug not addressed by -Bsymbolic. > Whatever the solution my point here and elsewhere is that when > there is a choice, making a lot of maintainers and developers > work hard (whether on code, scripts or upstream negotiations) is > almost always worse than fixing some part of the toolchain to do > the work for them by default (freedom dictates that the default > can be turned off). Reasonable, but unfortunately in this case we're going to have to aim a bit higher in the toolchain -- providing easy fixes that can be patched into autoconf/libtool-using projects so that upstream can implement symbol versioning on *all* platforms that support it. I think autoconf and libtool cover the vast majority of affected libs, nowadays. -- Steve Langasek postmodern programmer
Attachment:
pgpS38h5iYxwR.pgp
Description: PGP signature