-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Mar 9, 2007, at 3:14 AM, Martin Costabel wrote: > Daniel Johnson wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> On Mar 6, 2007, at 4:04 PM, aaron bryden wrote: >>> Okay, yes, i am seeing that even though locate didn't find the >>> one in >>> /usr/local it must be affecting the build. It still seems strange to >>> me that the error can say it is loading the one in /sw/lib but that >>> the version is wrong even though the version is correct. >> dyld loads symbols from the first matching library in its search >> path. Since /usr/local/lib/libpng.3.dylib comes first, that's >> what gets used, but since its compatibility_version is wrong, >> dyld just throws up its hands and gives up. It never actually >> gets to the symbols in /sw/lib/libpng.3.dylib. So yes, /sw/lib/ >> libpng.3.dylib could be loaded, but by then the symbols have >> already been resolved-- incorrectly. > > I have the habit of cursing dylib myself and of accusing it of > misbehavior, but I don't think this analysis is correct. If a > binary has been linked with /sw/lib/libpng.3.dylib, then this > library is loaded by dylib, even if /usr/local/lib/libpng.3.dylib > is present on the computer. If it isn't, there must be a reason. > The reason can be that > > - either /usr/local/lib/libpng.3.dylib has already been loaded > before by some other object, and then that object should be > identified and rebuilt linking to /sw/lib/libpng.3.dylib instead > of /usr/local/lib/libpng.3.dylib. But the output Aaron showed does > not indicate this scenario. > > - or that the environment variable DYLD_LIBRARY_PATH is set. There > was a time when also DYLD_FALLBACK_LIBRARY_PATH could have this > effect, even when it was not set explicitly, but I think this was > the case only in some early versions of OSX 10.4 and associated > xcode-2.0. Fink correspondingly used to set > DYLD_FALLBACK_LIBRARY_PATH to an empty ":" for a while, but it > doesn't do so any more. > > My bet is still that something in Aaron's startup scripts sets > DYLD_LIBRARY_PATH. I don't know if he ever showed the output of > > echo $DYLD_LIBRARY_PATH > > I would try to run > > env DYLD_LIBRARY_PATH="" pymol > > and see what happens. Er, yeah sorry. I wasn't clear. When I said "dyld loads symbols from the first matching library in its search path" I should have said that DYLD_*_PATH was part of that search path. Which turns out to be the problem here. It's almost always a problem when something messes with these environment variables. For some reason I thought this had been mentioned earlier. I misremembered. Daniel -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (Darwin) Comment: http://homepage.mac.com/danielj7/publickey.txt iD8DBQFF8rFt4sDFGYouOqARAmgHAJ9OOCK0TZWnIbX3/EcNQ+I7YyJLUwCfdGbi kiivmGqKwjagEOwZqeNcSeE= =zneN -----END PGP SIGNATURE----- ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Fink-beginners mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/fink-beginners
