Yes, I looked at this again and yes DYLD_LIBRARY_PATH is getting set to include /usr/local even though I don't know where or what would have set it. I removed the other libpng and pymol now works. Thank you very much, I was about to reinstall OS X as a whole and try again. Where other than the automatically executed scripts in my home directory do you look for environment variables in OS X?
Aaron On 3/9/07, Martin Costabel <[EMAIL PROTECTED]> 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. > > -- > Martin > > > > > ------------------------------------------------------------------------- > 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 > ------------------------------------------------------------------------- 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
