Re: On the cost of libraries

[Colm Smyth <Colm Smyth Sun COM>]

Different linkers do different things even on the same platform.

ELF binaries do not usually record the library location
or even it's name, so symbol resolution occurs using
a runtime search-path that depends on the way that the
shared object dependency was expressed at build time
and configurable properties of the runtime linker
(with Solaris ld that's LD_LIBRARY_PATH, /var/ld/ld.config
and other env-vars).

Again on Solaris, the '-B direct' parameter to ld
*does* actually record the dependency (.so) for each
symbol, which results in faster, statically deterministic
linkage. It can also be quite handy when trying to resolve
nasty problems, for example when trying to combine
two libraries that each expect to be able to override
the C++ global new() operator, you can specify a different
"global" new() symbol binding for each library!

That's interesting background, but it doesn't immediately
help with the problem; I've missed the earlier part of
this thread, but it seems to be that we are concerned with
the cost of simply recording a dependency on a library (shared
object).

There are several costs associated with a library:
a) invoking the designated "init" functions for the .so (time)
b) the global data of the library (space)
c) relocation (time)
d) symbol resolution, which may be done for all symbols immediately
  or on-demand when the symbol is first used (time)
  
Lazy loading allows you to avoid all of these costs provided no
symbol from the library is actually used but AFAIK  for most
linkers it decreases the determinism of symbol resolution
because the symbol may be found in any library of the application or its
dependent libraries rather than from the sub-tree of libraries that are 
explicitly recorded as deoendenies for an object at build-time.

Dynamic resolution only defers the work of step d) above, and it performs
it incrementally for symbols, on demand.

Colm.

>Delivered-To: gnome-private-members gnome org
>Delivered-To: gnome-hackers gnome org
>From: Drazen Kacar <dave arsdigita com>
>To: Sander Vesik <Sander Vesik Sun COM>
>Cc: Drazen Kacar <dave arsdigita com>, Owen Taylor <otaylor redhat com>, Alex 
Larsson <alexl redhat com>, Maciej Stachowiak <mjs noisehavoc org>, 
gnome-hackers gnome org
>Subject: Re: On the cost of libraries
>Mime-Version: 1.0
>X-Face: 
'UIE}WabGB0+U>p-#(hp<_+AD2{H],=qR*jHfm$/e]l0(kU3oOYc5lqG6gg>[\h^IOc{'siD6#!T&loI
ShgmYHz3#+*D38:|`~\BE,(W~Ol9BDfDwk'lKJ;Z{sY8E9(ME.E]'wvNO`$n#,;9Z`tOFcW/nHZq!BOS
rM>V?C<5DTw=<$<xxB~RP@|-Co<|COgeVi1ozw_W>{c{M2V+|)0jSUl&!+8%8nIBF(u:E>SZWM^e
>X-Attribution: Dave
>
>Sander Vesik wrote:
>> On Sun, 2 Sep 2001, Drazen Kacar wrote:
>
>> > Lazy loading breaks that. It is essentialy a contract which says to
>> > run-time linker that the symbol will be in the library that had it at link
>> > time, so it doesn't have to load libfoo. Interposition is bad for other
>> > reasons as well, so making this kind of contract doesn't look like an
>> > important limitation to me. It would be better to have libraries which
>> 
>> Actually, no, this is not *strictly* true - if library foo uses any
>> functions from library bar it should have been linked against it at the
>> moment library foo was created. Aong other things, this ensures that
>> loading order stays sane and does not cause too much mayhem.
>
>Yep.
>
>> > > AFAIK, ELF doesn't record _which_ shared library a reference is in,
>> > 
>> > That depends on your contract with the linker. ELF is just a file format.
>> 
>> It's not just a file format. The standard specifies quite a bit more than
>> just how the bits look like in the file, esp. when it comes to shared
>> objects.
>
>It does. So hash function cannot be changed, as well as some other things.
>
>> > The only way to do it is with DT_FILTER entries and lazy loading should
>> > work with that (I haven't tested, though).
>> 
>> No, you can move 'top level'symbols around otherwise aswell. DT_FILTER
>
>How?
>
>> Well, there are libaries for which lazy loading may be an advantage. For
>> example, in the case of libbonoboui examples, the library list presently
>> is:
>
>[...]
>>         libresolv.so.2 =>        
>
>If this is Solaris, you don't need this one. It's usually being detected
>by the configure scripts as a place where inet_aton() can be found
>(undocumented place, I know). For S8 and on, inet_aton() can be replaced
>with inet_pton(). For older releases, I'd either put it in equivalent of
>libgnomesupport or just link in statically. That small function doesn't
>justify pulling in the whole library. Although it will probably be pulled
>in by some other library.
>
>-- 
> .-.   .-.    Errors have been made. Others will be blamed.
>(_  \ /  _)
>     |
>     |        dave arsdigita com
>
>_______________________________________________
>gnome-hackers mailing list
>gnome-hackers gnome org
>http://mail.gnome.org/mailman/listinfo/gnome-hackers
>
>

_______________________________________________
gnome-hackers mailing list
gnome-hackers gnome org
http://mail.gnome.org/mailman/listinfo/gnome-hackers