On 6 Mar 2007, at 18:00, Christian Voelker wrote:
Hi,
Am 06.03.2007 um 21:33 schrieb Kevin Horton:
Or, is this cruft left over from my previous installed ports
I would try
port clean --work all
done
port clean --archive all
done
sudo periodic daily weekly monthly
done
Then check whether old python port were uninstalled properly:
port installed | grep py*
% port installed | grep py* zsh: no matches found: py*
Uninstall the stuff that might interfere with your current installation. Maybe this is best done first of all. Now, if it does not work afterwards, you can read your /etc/profile and .profile and .login files to find strange environment variable settings. Tell us about your findings.
I'm not sure exactly what the above means. Is this referring to Fink? If so, I changed my path to not have /sw/bin in it. Renaming / sw is a bit of a problem for me, as I discovered when I tried it earlier this afternoon. The way my login shells are set, they expect to find /sw. If not, they don't load, and I can't change from my normal, unpriviledged user to an user with administrative priviledges, And I can't rename it back to /sw as my normal user. I eventually had to reboot in Target Disk Mode, and use another Mac to sort things out. Ugh. After doing all the above, python24 builds. But, looking at the build output, I see hundreds of references to /sw/lib or /sw/include, e.g. /usr/bin/gcc-4.0 -bundle -undefined dynamic_lookup build/ temp.darwin-8.8.0-Power_Macintosh-2.4/grpmodule.o -L/opt/local/lib -L/ sw/lib -L/usr/local/lib -o build/lib.darwin-8.8.0-Power_Macintosh-2.4/ grp.so Where are these coming from, if /sw is not in my path? Is there no way to prevent MacPorts from being polluted with Fink stuff, short of renaming or removing /sw? If renaming it works, why wouldn't removing it from the path work? Are new login shells being created, and my login scripts are putting /sw in their paths? Or, is /sw in the default search path for the python build? Kevin Horton Ottawa, Canada