On Mon, Dec 9, 2013 at 7:43 AM, Brian D. McGrew <br...@visionpro.com> wrote:
> Ah, right, thanks for the clarification. We set > DYLD_FALLBACK_LIBRARY_PATH, not the other. But, I don't set that in a new > terminal. I have to run a script that sets up my build environment, which > is 'usually' the first thing I do. So popping a new terminal and running > port without my build environment works fine. But, if I set my env and > DYLD_FALLBACK… is set, it no workee… very slow, don't know why. but the > fix, I just won't have DYLD_ set when I run port. Still, never seen this > before and if anyone knows why it's happening, I'd be interested in knowing. > We can't tell for certain without knowing what your environment looks like, but it is very likely that your replacement libraries are shadowing some standard function in a way that breaks MacPorts (and may affect other OS X native software although perhaps not as drastically). There are some debugging DYLD_ variables you can set to show what is getting bound from where, but without knowing what's in the libraries you have been forcing it to use we can't even guess. -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net
_______________________________________________ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
