Re: Stupid library ABI question
On Wed, Jan 10, 2007 at 09:36:28AM -0800, Kevin B. McCarty wrote:
> Thanks everyone who answered so far! Unfortunately some of the answers
> (Steve Langasek's vs. Neil Williams') seem directly opposed :-) I'd
> like to try to understand this better since I really know very little
> technical detail about how the runtime linker works.
>
> Neil Williams wrote:
> > On Mon, 08 Jan 2007 11:19:40 -0800
> > "Kevin B. McCarty" <kmccarty@Princeton.EDU> wrote:
> Let me ask another question that will possibly show the amount of my
> ignorance :-) If a library stops shipping certain symbols (so that the
> soversion *should* definitely be bumped, but *isn't*), but no
> applications or other libraries actually use those symbols, then what
> happens to programs built against the old library but now using the new one?
>
> a) They segfault because the new version of the library is missing symbols
> b) They work properly because they don't use the missing symbols
> c) Something in between (?)
>
> There are no other interface changes in the library (i.e. function APIs
> and structs that still exist all stay the same).
If it uses the symbol, it will get:
./a.out: symbol lookup error: ./a.out: undefined symbol: f
and [ $? -eq 127 ].
If it doesn't use the symbol it will work fine.
BUT WAIT THERE'S MORE
======================
Normally the symbols are resolved "lazily"; symbols which are never
used are never looked up (and the lookup uses some crazy 2 layer
indirection or such so the lookup itself happens only once, after
which it is 1 layer only).
|int main()
|{
| sleep(2);
| return f();
|}
This will end up exiting 127, but take 2 seconds to do so. You can
set environment variables and linker options causing all lookups to
happen at startup.
SEE ALSO
ld-linux(8), (note that the manpage may still be outdated)
ld(1),
http://g.rtfo.org/Ulrich+Drepper+DSO
Justin
Reply to: