Re: On the cost of libraries
- 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
- Date: Sun, 2 Sep 2001 23:43:35 +0200
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
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]