On Jun 24, 2008, at 12:55 PM, Martin Costabel wrote:
Daniel Johnson wrote: []I just checked the 10.5.3 combo updater and while it installs new libxrandr.2.1.0.dylib and libxrandr.2.dylib, it does NOT install a new libxrandr.la file. So the .la file still points to libxrandr. 2.0.0.dylib. Now the update SHOULDN'T delete libxrandr.2.0.0.dylib (I still have mine) but apparently Max's went awayNo, the problem is with machines that came with 10.5.2 preinstalled. They don't have the 2.0.0 symlink. I can no longer verify this, because on the only machine I have that came with 10.5.2 preinstalled I did various xquartz updates thatt change these files too.
Ah yes, I hadn't taken into account that pre-installed 10.5.2 did this. So, even more of a bug on Apple's part since X11 is very broken on such systems and upgrading to 10.5.3 won't help. Apple's really screwed up X11 on Leopard. :( The only way to be sure you have a complete X11 is to install the macosforge package, which causes other issues.
somewhere. As long as that file is still there, things will (accidentally) work. But that .la file really SHOULD be updated, and it's a bug that it isn't. If you install the X11 package from macosforge, it does update it to use 2.1.0. The simplest fix is to recreate the libxrandr.2.0.0.dylib symlink to point to libxrandr.2.dylib. Incidentally, it's a feature that libtool uses /usr/X11/lib/ libXrandr.2.0.0.dylib explicitly, not a bug. Each .la file belongs to a specific library version, so that multiple versions can coexist on the system. Apple just neglected to update the file when they updated the library.That's exactly what Apple got backwards. They put the real file into libXrandr.2.dylib, whatever its minor version, and they create symlinks (often several of them) with fake minor version numbers that all point to the same file. This does not make sense.
No argument.
Anyway, multiple coexisting versions of a dylib only make sense if they have different install_names, otherwise they won't be found by their respective executables. And this is never the case, neither with Apple's variant nor with the standard gnu libtool variant of the symlinking game. The only thing that you can have with the gnu libtool variant is several different coexisting compatibility_versions of the same dylib with the same install_name. With Apple's variant you can't even have this.Apple's way: - install_name=libfoo.X.dylib, - real file libfoo.X.dylib, - symlinks libfoo.X.y.z.dylib and libfoo.X.a.b.dylib, - both pointing to libfoo.X.dylib Gnu libtool's way: - install_name=libfoo.X.dylib, - real files libfoo.X.y.z.dylib and libfoo.X.a.b.dylib,- one symlink either pointing to libfoo.X.y.z.dylib or to libfoo.X.a.b.dylib.In addition, both have the compile-time symlink libfoo.dylib that points to the install_name. And that's what IMHO libtool should use in any case.
Yes, it's backwards, but libtool is still doing what it thinks is right. I believe that the X.y.z naming convention is a holdover from Linux, which doesn't have the concept of compatibility_version. Libtool 2 simplifies lib naming on OS X but isn't widely adopted yet. In any case, libtool can't know that the system is being abused. Despite its complexity, libtool has not yet achieved sentience. :)
I wonder if it's actually the xorg build system that is at fault here rather than Apple. The macosforge package does the same thing. Of course, if Apple had just included the updated .la file this wouldn't be an issue. In any case, the results are headaches for Fink users/ maintainers. Thanks Apple!
Daniel
smime.p7s
Description: S/MIME cryptographic signature
------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php
_______________________________________________ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel
