Re: Neat gtk/gdk-imlib pain
On 1 Feb 1999, Gordon Matzigkeit wrote:
> Hi!
>
> >>>>> Jim Pick writes:
>
> JP> The only problem is, for libgnome, the library might end up
> JP> looking like:
>
> JP> libgnomeui-31-esd0-glib1.1.3-gtk1.1.3-imlib1.so
>
> JP> Gawd knows what I'd name the package as.
>
> No kidding.
>
> JP> It's just a variation on the bumping the soname idea.
>
> I'm now convinced that the problem can't be solved without changing
> ld.so. I have some ideas about how this could be done... I'll do some
> experimentation, then chat with the glibc folks (who tend to be pretty
> anal about elegance, so if we come up with a solution that works,
> it'll be as elegant as it can be).
OK.
I've read this thread with interest. All of it. I've refrained from
commenting up until now since I am relatively uninformed on dynamic
library internals. However, I'm going to briefly break silence now:
1) -rpath is *evil*. It really is. It is an appalling idea to hardwire
paths into anything. The only cases I can think of where hardwiring paths
is common and sensible is for security reasons. Now, there may be some
perfectly valid applications of rpath - although every single one which
has been mentioned so far, I'd much rather see solved with a simple
LD_LIBRARY_PATH wrapper. It seems to me such a foolish assumption that
any other machine will have the same directory structure as the one you
compile on. Surely a more reasonable assumption is that the linker on the
destination machine can find the library concerned without your help?
So, for this reason, I really don't understand why, in a perfect world,
-rpath should be the default option for libtool.
2) Yes, our dynamic linker is suboptimal. Severely so. Now, it seems to
me, crudely, that the correct answer is this:
Application X links to s {A,B,C,D}. So the dynamic linker finds all the
libraries it can which provide those sonames:
A is provided by {A1,A2,A3}
B is provided by {B1,B2,B3}
...
Then, the linker finds out which libraries each of the libraries above
depends on. Repeat...
Now, the linker picks one of the Ai, one of the Bi, one of the Ci and one
of the Di such that there are no conflicts. Where a conflict is what you
have when something depends on libfoo.1 and something else depends on
libfoo.2.
In my analysis, this requires some extra capability in the dynamic linker,
as follows: The dynamic linker is unable to tell (am I right?) that
libfoo.1 and libfoo.2 are in fact incompatible instances of the same
library. So, we need to give the dynamic linker this information somehow.
If the dynamic linker did have this information, then it could build some
clever internal cache graphs which would essentially autogenerate the kind
of information jimpick was talking about when he talked of extending the
soname. I.e, ld.so 'knows' that libtiff.so.3 is really
libtiff.so.3-libc.so.6-libjpeg.so.62-libz.so.1-libm.so.6
(It also knows that imlib has a stupidly long 'real' so name, but at least
this never has to be made explicit in the userland)
For example, it does know that /usr/X11R6/lib/libX11.so.6 is really
'libX11.so.6-libc.so.6', while '/usr/lib/libc5-compat/libX11.so.6' is
really 'libX11.so.6-libc.so.5'.
In other words, this is the logical completion of our current hack.
However, I am slightly worried about the idea that I am defining
libraries as incompatible simply by regular expression matching (if they
match up to the numerical bit of the soname they are incompatible).
Obviously, this could be made robust simply by imbedding the soname in two
bits into the library - essentially making explicit the split of
'soname' into 'interface name' and 'interface version'.
However, I'm glossing over the fact that unrelated libraries can still
have symbol collisions. Either accidentally, or in fact deliberately. So
what we really want to say is 'libraries are incompatible if their symbol
tables collide'. Except that I believe I'm right in saying that sometimes
it is *OK* for symbol tables to collide, and we simply want the last
library on the link line to override.
*sigh*
Phew. In fact, a far cleaner solution to the problem would be to have in
your library header a list of 'interfaces provided' and 'interface
versions'. Then the dyn-linker could make sure that it didn't link
together anywhere in the library chain two different libraries providing
the same interface at different versions.
This is becoming off-topic for -devel, I suspect. I imagine Gordon knows
who to forward this to at gnu - and if this thread does continue, please
keep me in the Cc:.
Jules
/----------------+-------------------------------+---------------------\
| Jelibean aka | jules@jellybean.co.uk | 6 Evelyn Rd |
| Jules aka | jules@debian.org | Richmond, Surrey |
| Julian Bean | jmlb2@hermes.cam.ac.uk | TW9 2TF *UK* |
+----------------+-------------------------------+---------------------+
| War doesn't demonstrate who's right... just who's left. |
| When privacy is outlawed... only the outlaws have privacy. |
\----------------------------------------------------------------------/
Reply to: