Re: On the cost of libraries

[Drazen Kacar <dave willfork com>]

Colm Smyth wrote:

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

Be very careful with that flag. It asserts -z lazyload on all dependencies
and that can have disasterous effects. For example, with the default
installation from the source tarball, libgtk is not linked against libgdk.
If you use "-z lazyload -lgtk ..." when building the binary and the binary
doesn't have copy relocations against libgdk, a call to gtk_init() will
fail with the error from the run-time linker, because it won't be able to
locate gdk_init(). Maybe even if there are copy relocations; I don't
remember any more.

In order to make lazyloading of some library usefull, the library should
record all its dependencies. By and large, the default installation
procedures for the Gnome libraries don't do this.

I've been experimenting with -B direct a bit, found some bugs which have
been fixed by now, although all fixes are not publicaly available at the
moment, but I still don't have an opinion about its usefulness.  What
bothers me the most with -B direct is that I don't know in which
situations it would be dangerous. OK, I know some, but I don't think I
have the complete list.

I haven't had the time to look into Jakub's work, so I cannot comment on
that, but it's perfectly possible that it's superior.

Could somebody post a list of things that could go wrong (at least in
theory) with that approach? I couldn't find anything in the tarball.

Solaris has something like that (although not explicit support in the
run-time linker for all features). It also has some nasty warnings in the
documentation, so it makes me wonder.

Anyway, I think that putting some of the more esoteric -B or -z Solaris
flags into public sources for Gnome 1 at this point would be a mistake. I
don't know about Gnome 2; it depends on the build system and I don't know
much about it.

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

Uh... I think this would backfire sooner or later. How about using -B group
or -z groupperm instead?

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