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 away
No, 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. > 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. 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. -- Martin ------------------------------------------------------------------------- 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
