[Xquartz-dev] Why are dylib symlinks backwards?

[Martin Costabel]

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