Re: [Fink-devel] pangocairo: Error building gtk+2-2.12.10-1
On Jun 24, 2008, at 5:52 PM, Max Horn wrote: > So probably not much we can do about this, other than praying Apple > will do something about it in 10.5.4. How about filing a bug report? ;-) - Koen. - 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
Re: [Fink-devel] pangocairo: Error building gtk+2-2.12.10-1
Hi folks, yeah, this sounds bad. My system indeed came with 10.5.2 preinstalled, and the .la file is bad, just as Martin predicted. For now, instead of creating a libXrandr.2.0.0.dylib symlink, I modified libXrandr.la to use 2.1.0 instead of 2.0.0. So probably not much we can do about this, other than praying Apple will do something about it in 10.5.4. Thank you for your patience with me, Max - 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
Re: [Fink-devel] pangocairo: Error building gtk+2-2.12.10-1
Daniel Johnson wrote: [] > 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! In the X11 parts, the quality control is particularly low, but the symlink weirdness is not restricted to it (the lib*.la files are perhaps a little weirder in X11 than elsewhere). If you look into /usr/lib/, you see a colorful mixture of examples for both variants (compare /usr/lib/libiconv*dylib with /sw/lib/libiconv*dylib, for instance), plus all sorts of hand-crafted symlinks, with /usr/lib/libreadline.dylib as the famous lonely summit of madness. -- 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
Re: [Fink-devel] pangocairo: Error building gtk+2-2.12.10-1
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 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. 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
Re: [Fink-devel] pangocairo: Error building gtk+2-2.12.10-1
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
Re: [Fink-devel] pangocairo: Error building gtk+2-2.12.10-1
On Jun 24, 2008, at 4:50 AM, Martin Costabel wrote: Max Horn wrote: [] So, the "missing symlink" is indeed back (i.e. Apple has fixed the bug on its part), but libtool is translating a -lXrandr to an explicit /usr/X11/lib/libXrandr.2.0.0.dylib. I have not yet discovered why it does that, though *sigh*. Usually libtool takes what it finds in the corresponding *.la file. That was always the origin of the problem, that libXrandr.la had a last entry in its library_names line (which is what libtool uses) which did not correspond to the really existing files or symlinks. I have the suspicion that someone at Apple's is doing these symlinks in /usr/X11/lib by hand. Pogma says they are created by Apple's in-house version of gnu libtool, but they are so weird and useless - except for causing occasional linker crashes - that I find it hard to believe that they are created by an automatic and deterministic tool. 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 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. 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
Re: [Fink-devel] pangocairo: Error building gtk+2-2.12.10-1
Max Horn wrote: [] > So, the "missing symlink" is indeed back (i.e. Apple has fixed the bug on > its part), but libtool is translating a -lXrandr to an explicit > /usr/X11/lib/libXrandr.2.0.0.dylib. I have not yet discovered why it does > that, though *sigh*. Usually libtool takes what it finds in the corresponding *.la file. That was always the origin of the problem, that libXrandr.la had a last entry in its library_names line (which is what libtool uses) which did not correspond to the really existing files or symlinks. I have the suspicion that someone at Apple's is doing these symlinks in /usr/X11/lib by hand. Pogma says they are created by Apple's in-house version of gnu libtool, but they are so weird and useless - except for causing occasional linker crashes - that I find it hard to believe that they are created by an automatic and deterministic tool. -- 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
Re: [Fink-devel] pangocairo: Error building gtk+2-2.12.10-1
Am Di, 24.06.2008, 10:21, schrieb Martin Costabel: > Max Horn wrote: >> Hi folks, >> >> tried to update to gtk+2-2.12.10-1 today, on my 10.5.3 machine. Well, >> it fails: >> >> >> i686-apple-darwin9-gcc-4.0.1: /usr/X11/lib/libXrandr.2.0.0.dylib: No >> such file or directory > > So you still have the same problem you reported on the gnome-core list a > month ago, when your macbook was new and running 10.5.2. Weird, I > thought this was fixed in 10.5.3? Does your /usr/X11/lib/libXrandr.la > still have libXrandr.2.0.0.dylib in its library_names line? > Hi, AFAIK it is not the same problem (but I might be wrong): With 10.5.3, libXrandr was updated from 2.0.0 to 2.0.1. All the 2.0.1 files are still there, but the 2.0.0 files are not anymore. In particular, I do NOT have /usr/X11/lib/libXrandr.2.0.0.dylib but I *do* have /usr/X11/lib/libXrandr.2.0.1.dylib So, the "missing symlink" is indeed back (i.e. Apple has fixed the bug on its part), but libtool is translating a -lXrandr to an explicit /usr/X11/lib/libXrandr.2.0.0.dylib. I have not yet discovered why it does that, though *sigh*. Max - 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
Re: [Fink-devel] pangocairo: Error building gtk+2-2.12.10-1
Max Horn wrote: > Hi folks, > > tried to update to gtk+2-2.12.10-1 today, on my 10.5.3 machine. Well, > it fails: > > > i686-apple-darwin9-gcc-4.0.1: /usr/X11/lib/libXrandr.2.0.0.dylib: No > such file or directory So you still have the same problem you reported on the gnome-core list a month ago, when your macbook was new and running 10.5.2. Weird, I thought this was fixed in 10.5.3? Does your /usr/X11/lib/libXrandr.la still have libXrandr.2.0.0.dylib in its library_names line? -- 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
