I wanted to follow up on this message, because Apple's X11.app team may have
overlooked it.
Here's the effect of this problem with the -install_name: if I compile another
app against Apple's X11 release, then at runtime the X11 libraries will be
searched for at
/usr/X11R6/lib/libX11.6.2.dylib
while if I compile it against the XFree86 release or Fink's release (or,
presumably, the GNU-Darwin release), then the libraries will be searched for
at
/usr/X11R6/lib/libX11.6.dylib
Since there are symlinks in place, there is no immediate problem.
However, serious problems will arise the next time the XFree86 project updates
its libraries. If libX11 goes to 6.3, then in the standard release, there
will be a symlink from /usr/X11R6/lib/libX11.6.dylib pointing to the new lib
/usr/X11R6/lib/libX11.6.3.dylib and all previously compiled apps will still
work. However, under Apple's release, either all of the old 6.2 versions will
continue to need to be shipped (with *every* update until the "6" changes), or
anyone who has compiled apps against the library will get failures from dyld
upon loading and will have to recompile.
-- Dave
On Jan 10,2003 13:07:22 +0100, Martin Costabel
<email@hidden> wrote :
The dylibs in /usr/X11R6/lib come in triples,
libXsomething.dylib, libXsomething.v.dylib, libXsomething.v.r.dylib,
for example
libX11.dylib, libX11.6.dylib, libX11.6.2.dylib
The third of these is the real file, the first two are symlinks to the
third.
The install_name of all three of them should be the second one, in the
example libX11.6.dylib.
It is like this in any standard compilation of xfree86, whether
directly form the sources or from Fink. It is also the whole idea of
this construction, namely when a new minor revision libX11.6.3.dylib
comes out, the binaries that were compiled against libX11.6.2.dylib
will continue to work, because they have libX11.6.dylib in their
library list, and this still exists and is compatible to the preceding
revision.
Not so for Apple's X11. Apple has put libX11.6.2.dylib as
install_name. Not only this defies the whole construction of this
two-level symlink method, but it causes compatibility problems and
crashes. This has already been reported in compilations where
multiply-defined symbols errors appear, because now libX11.6.dylib and
libX11.6.2.dylib are seen as two different libraries.
Is there some reason behind this, or is it just a bug?
--
Martin
_______________________________________________
x11-users mailing list | email@hidden
Help/Unsubscribe: http://www.lists.apple.com/mailman/listinfo/x11-users
>Do not post admin requests to the list. They will be ignored.