Here is a question I always wanted to ask: Why are most of the symlinks in Leopard's /usr/X11/lib backwards? Here is an example: `ls -l /usr/X11R6/lib/libGLU*b` shows on Tiger: 1124148 Nov 7 2006 /usr/X11R6/lib/libGLU.1.3.dylib 16 Nov 16 2006 /usr/X11R6/lib/libGLU.1.dylib -> libGLU.1.3.dylib 16 Nov 16 2006 /usr/X11R6/lib/libGLU.dylib -> libGLU.1.3.dylib which makes a lot of sense, but on Leopard: 14 Oct 28 13:12 /usr/X11R6/lib/libGLU.1.3.dylib -> libGLU.1.dylib 3304064 Sep 24 07:21 /usr/X11R6/lib/libGLU.1.dylib 14 Oct 28 13:12 /usr/X11R6/lib/libGLU.dylib -> libGLU.1.dylib which does not make sense. The install_name corresponds in both cases to libGLU.1.dylib, so on Tiger you have the 3 clear roles: Link time: libGLU.dylib Run time : libGLU.1.dylib Implementation: libGLU.1.3.dylib On Leopard, libGLU.1.3.dylib does not play any role. You cannot even say it is there for compatibility reasons, because this file is not needed at runtime. In fact, on Leopard it is not needed at all. Are these symlinks made by hand, or are they the result of some weird build system? If gnu libtool was used for compilation, this would not happen. A quick grep in Leopard's /usr/X11/lib shows 72 backward symlinks and only 3 right ones: libfontconfig, libfreetype and libX11. I remember that when Apple released its first X11 beta, it also had these backward symlinks, I protested against it, and it was in fact fixed rather quickly. Why is this coming back now? There is a lot of the same nonsense also in /usr/lib, and there it is already present on Tiger. -- Martin
Martin Costabel wrote:
Here is a question I always wanted to ask:
Why are most of the symlinks in Leopard's /usr/X11/lib backwards?
Here is an example: `ls -l /usr/X11R6/lib/libGLU*b` shows
on Tiger: 1124148 Nov 7 2006 /usr/X11R6/lib/libGLU.1.3.dylib 16 Nov 16 2006 /usr/X11R6/lib/libGLU.1.dylib -> libGLU.1.3.dylib 16 Nov 16 2006 /usr/X11R6/lib/libGLU.dylib -> libGLU.1.3.dylib which makes a lot of sense, but
on Leopard: 14 Oct 28 13:12 /usr/X11R6/lib/libGLU.1.3.dylib -> libGLU.1.dylib 3304064 Sep 24 07:21 /usr/X11R6/lib/libGLU.1.dylib 14 Oct 28 13:12 /usr/X11R6/lib/libGLU.dylib -> libGLU.1.dylib which does not make sense.
Apple's version of GNU libtool does this. IIRC when it first did so, it was because one of the tools (I forget which) requires the install_name to be the actual library, not a symlink. Without the change there would be a libfoo.1.dylib and libfoo.1.3.dylib both with actual code because of the way that tool worked. With the way it is now with Apple's libtool there is a useless symlink, but at least the filenames generated by the same version of GNU libtool upstream are the same and it is unlikely that anyones tools or scripts would break. Tiger's version did not use GNU libtool. Should we (upstream GNU libtool) ever get around to releasing libtool-2.x there will be one library and one symlink (libfoo.dylib -> libfoo.1.dylib), with no useless symlink. Peter -- Peter O'Gorman http://pogma.com
participants (2)
-
Martin Costabel
-
Peter O'Gorman