Re: On the cost of libraries

[Sander Vesik <Sander Vesik Sun COM>]

On Sun, 2 Sep 2001, Drazen Kacar wrote:

> Owen Taylor wrote:
> > Because of the way symbol lookups in ELF works, even if there are no
> > copy relocations pointing to a library, the first time the linker
> > needs to look up a symbol that is in a library after those libraries
> > in the link order, it's going to load up those libraries.
> > 
> > That is, if I have   gcc -o a.out main.c -lfoo -lbar
> > 
> > then if main.c references bar_a(), then there is no way the runtime
> > linker can avoid loading libfoo to see if bar_a() is in
> > libfoo. 
> 
> 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.

> were well designed, in which case lazy loading wouldn't give much benefit.
> But if they are not well designed, tricks like this can help.
> 

The effect lazy loading is ever going to have anywhere is startup time.
Yes, if you linking againsta shared library that you don't actually use
during a specific run of the program, it has a bit more benefits, but it's
primamrily targeted at program startup.

> > 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.

> > just that the  reference is in some external shared library. 
> > (Which has advantages ... under ELF, you can move symbols around
> > between shared libs without breaking bin compat, and you have
> 
> 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
allows you to do something else - namely linking against only a portion of
library, so that if you knew you were only using 25% of teh libary, you
could create a filter and the other 75% of the library wouldn't be
bothered with.

> > the LD_PRELOAD capability.) 
> 
> That's not a problem in any case, because it's explicitely marked as
> an interposer.
> 
> > Also, I'll point out, your example is quite unusual. It's not
> > often you have an executable that links to GTK+ but doesn't
> > use in most cases.
> 
> Yes, which is why I didn't use lazy loading when linking libgtk in the
> first place.
> 

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:
        libbonoboui-2.so.0 =>
        libgnomecanvas-2.so.0 =>
        libart_lgpl.so.2 =>
        libpangoft2-0.17.so =>
        libfreetype.so.6 =>
        libgtk-x11-1.3.so.7 =>
        libgdk-x11-1.3.so.7 =>
        libXext.so.0 => 
        libgdk_pixbuf-1.3.so.7 =>
        libpangox-0.17.so =>
        libX11.so.4 =>  
        libpango-0.17.so =>
        libatk.so.2 =>
        libgnome-2.so.0 =>
        libgnomevfs.so.0 =>
        libsocket.so.1 => 
        libnsl.so.1 => 
        libbonobo-2.so.0 =>
        libORBitCosNaming-2.so.1 =>
        libbonobo-activation.so.1 =>
        libORBit-2-2.3.94.so.1 =>
        libpopt.so.0 => 
        liblinc.so.0 => 
        libgobject-1.3.so.7 =>
        libresolv.so.2 =>        
        libgmodule-1.3.so.7 =>
        libdl.so.1 =>   
        libgthread-1.3.so.7 =>
        libthread.so.1 =>       
        libglib-1.3.so.7 =>
        libxml2.so.2 => 
        libm.so.1 =>    
        libz.so.1 =>     
        libc.so.1 =>     
        libiconv.so.2 =>
        libmp.so.2 =>   

I don't know exactly which subset of this actually gets used during
startup. The list won't really be different for gnome2 apps based on
libbonoboui.

[snip]

> 
> -- 
>  .-.   .-.    Errors have been made. Others will be blamed.
> (_  \ /  _)
>      |
>      |        dave arsdigita com
> 

	Sander

I haven't been vampired. You've been Weatherwaxed.


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