[issue8453] build_installer.py breaks bzip compilation

R. David Murray added the comment: I don't think bash itself has a default path, I think the default path is set by the system bash profile, and is therefore system dependant. I could be wrong, though. -- nosy: +r.david.murray ___ Python tracker

[issue8453] build_installer.py breaks bzip compilation

Ned Deily added the comment: +1. Thanks, all. -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.p

[issue8453] build_installer.py breaks bzip compilation

David Bolen added the comment: The buildbot user's shell is also bash, so not entirely sure yet why it's behaving differently in my environment. I had completely forgotten about bash having a default path. I do agree that explicitly setting a minimal path is a good idea. -- ___

[issue8453] build_installer.py breaks bzip compilation

Changes by Martin v. Löwis : -- resolution: -> fixed status: open -> closed ___ Python tracker ___ ___ Python-bugs-list mailing list U

[issue8453] build_installer.py breaks bzip compilation

Martin v. Löwis added the comment: That fixes it indeed, see http://www.python.org/dev/buildbot/builders/2.7.dmg/builds/11/steps/compile/logs/stdio As for "which shell is being used": the slave reports that in his environment, there is SHELL=/bin/bash Not sure whether this actually means th

[issue8453] build_installer.py breaks bzip compilation

Ronald Oussoren added the comment: r80232 explicitly sets $PATH to the system default one, which hopefully fixes the issue. What would be interesting to know is which shell is the user shell on the buildbot. The original patch worked for me because my shell is bash and bash sets a default $P

[issue8453] build_installer.py breaks bzip compilation

David Bolen added the comment: I believe it's XCode 2.4.1. I know the script worked fine prior to the change that clears the environment, and commenting out just that piece of the latest trunk copy continues to work. To be honest, I'm not sure how the build even finds gcc-4.0 (e.g., why it d

[issue8453] build_installer.py breaks bzip compilation

Martin v. Löwis added the comment: I personally can't verify what version of Xcode is installed. David? In any case, David reported that he could build installers just fine on that very machine before r80179, but not after. -- nosy: +db3l ___ Pytho

[issue8453] build_installer.py breaks bzip compilation

Ned Deily added the comment: (er, "ranlib") -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.pyth

[issue8453] build_installer.py breaks bzip compilation

Ned Deily added the comment: I still don't understand why that isn't showing up in my environment (I've been running with that change for over a year) and I can't see why ld would fail but ar and ran don't. Can you verify the version of Xcode that has been installed? Perhaps there is an old

[issue8453] build_installer.py breaks bzip compilation

Martin v. Löwis added the comment: David Bolen reported that this occurs with r80179, which now clears the PATH environment variable, removing ld from the path. -- ___ Python tracker __

[issue8453] build_installer.py breaks bzip compilation

Ned Deily added the comment: Odd, works for me on 10.4, 10.5, and 10.6 (but I have never tried running under buildbot, if that is what is happening here). For 10.4 with its most-recent Xcode installed: $ /usr/bin/ld -v Apple Computer, Inc. version cctools-622.9~2 $ /usr/bin/gcc -v Using bui

[issue8453] build_installer.py breaks bzip compilation

New submission from Martin v. Löwis : The current build_installer fails to build dependencies, e.g. with gcc-4.0 -arch i386 -arch ppc -isysroot /Developer/SDKs/MacOSX10.4u.sdk -o bzip2 bzip2.o -L. -lbz2 collect2: cannot find 'ld' collect2: cannot find 'ld' lipo: can't open input file: /var/tmp