While bootstrapping prefix and building python I found that python is importing the system's python frameworks which eventually grabs flags that only with with Apple's gcc. Since python is being built with gcc in prefix, the build fails. Reproducible: Always Steps to Reproduce: 1. build python on OSX Snow Leopard under the prefix env 2. watch it die miserably as "-arch" is not a valid flag to prefix' gcc Actual Results: modules are not built Expected Results: python build should complete successfully. I tried removing the -DWITH_FRAMEWORKS CCFLAG but the build process is still finding the OSX frameworks.
Do you have a buildlog for me please? I don't have Snow Leopard, and you're the first SL user to report such failure.
Created attachment 213786 [details] build log vanilla build.log
Do you by chance have DYLD_LIBRARY_PATH set? The following is really worrysome: dyld: lazy symbol binding failed: Symbol not found: _iconv_open Referenced from: /usr/lib/libaprutil-1.0.dylib Expected in: /apps/dist/x86_64-apple-darwin10/lib/libiconv.2.dylib
yes I do: >echo $DYLD_LIBRARY_PATH /apps/dist/x86_64-apple-darwin10/lib:/apps/dist/x86_64-apple-darwin10/usr/lib
That's asking for trouble, and I don't support such deadly settings. Can it be that you also changed LDFLAGS and PATH? I'd advise you to just unset any of those settings, and just follow the bootstrap document precisely.
I'm not sure why that setting is considered dangerous here? CFLAGS/LDFLAGS is not set. UNSETTING DYLD_LIBRARY_PATH has the effect of getting past the lazy symbol loading warning but the original problem of this bug report remains. Specifically, setup.py imports sysconfig from the systems distutils (in the Apple Framework path) and then sets the CFLAGS env var for building modules to include -arch for building universal binaries. it gets these flags from sysconfig. >grep -n sysconfig.\*CFLAGS setup.py 210: (ccshared,cflags) = sysconfig.get_config_vars('CCSHARED','CFLAGS') 1504: cflags = sysconfig.get_config_vars('CFLAGS')[0] Since the prefix gcc does not support -arch the modules fail: gcc -m64 -fno-strict-aliasing -DNDEBUG -march=nocona -DWITH_NEXT_FRAMEWORK -arch i386 -arch ppc -arch x86_64 -I. -I/apps/dist/x86_64-apple-darwin10/var/tmp/portage/dev-lang/python-2.6.4/work/Python-2.6.4/./Include -I/apps/dist/x86_64-apple-darwin10/var/tmp/portage/dev-lang/python-2.6.4/work/Python-2.6.4/./Mac/Include -I/apps/dist/x86_64-apple-darwin10/usr/include -I. -IInclude -I./Include -I/usr/include -I/apps/dist/x86_64-apple-darwin10/var/tmp/portage/dev-lang/python-2.6.4/work/Python-2.6.4/Include -I/apps/dist/x86_64-apple-darwin10/var/tmp/portage/dev-lang/python-2.6.4/work/Python-2.6.4 -c /apps/dist/x86_64-apple-darwin10/var/tmp/portage/dev-lang/python-2.6.4/work/Python-2.6.4/Modules/_struct.c -o build/temp.macosx-10.6-universal-2.6/apps/dist/x86_64-apple-darwin10/var/tmp/portage/dev-lang/python-2.6.4/work/Python-2.6.4/Modules/_struct.o cc1: error: unrecognized command line option "-arch" cc1: error: unrecognized command line option "-arch" cc1: error: unrecognized command line option "-arch" The only option granted to configure form the ebuild that mentions Frameworks is via setting CFLAGS=-DWITH_NEXT_FRAMEWORK which seems wrong given that configure has real flags to enable/disable framework usage on OSX. Furthermore, removing -DWITH_NEXT_FRAMEWORK does not actually stop the python build from using frameworks. I took the instructions for bootstrapping prefix and turned them into a makefile. I have only made small adjustments here and there to make prefix bootstrap correctly on our various architectures which include other versions/platforms of OSX. The same procedure has worked there.
I'm not convinced. I should have encountered this problem myself, since it doesn't seem Snow Leopard related to me. What stage in the bootstrap (the document) are you? Is this in the emerge -e system phase?
I'm here: env FEATURES="-collision-protect" emerge --oneshot portage Ah, but it is a snow leopard issue... OSX Tiger (x86): $ /usr/bin/python Python 2.3.5 (#1, Jan 12 2009, 14:13:25) [GCC 4.0.1 (Apple Computer, Inc. build 5363) (+4864187)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> from distutils import sysconfig >>> sysconfig.get_config_vars('CCSHARED','CFLAGS') ['', '-fno-strict-aliasing -Wno-long-double -no-cpp-precomp -mno-fused-madd -fno-common -dynamic -DNDEBUG -g -O3 -Wall -Wstrict-prototypes'] OSX Leopard (PPC): $ /usr/bin/python Python 2.5.1 (r251:54863, Feb 6 2009, 19:02:12) [GCC 4.0.1 (Apple Inc. build 5465)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> from distutils import sysconfig >>> sysconfig.get_config_vars('CCSHARED','CFLAGS') ['-pipe', '-fno-strict-aliasing -Wno-long-double -no-cpp-precomp -mno-fused-madd -fno-common -dynamic -DNDEBUG -g -Os -Wall -Wstrict-prototypes -DMACOSX -I/usr/include/ffi -DENABLE_DTRACE'] OSX Leopard (x86): $ /usr/bin/python Python 2.5.1 (r251:54863, Feb 6 2009, 19:02:12) [GCC 4.0.1 (Apple Inc. build 5465)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> from distutils import sysconfig >>> sysconfig.get_config_vars('CCSHARED','CFLAGS') ['-pipe', '-fno-strict-aliasing -Wno-long-double -no-cpp-precomp -mno-fused-madd -fno-common -dynamic -DNDEBUG -g -Os -Wall -Wstrict-prototypes -DMACOSX -I/usr/include/ffi -DENABLE_DTRACE'] OSX Snow Leopard: $ /usr/bin/python Python 2.6.1 (r261:67515, Jul 7 2009, 23:51:51) [GCC 4.2.1 (Apple Inc. build 5646)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> from distutils import sysconfig >>> sysconfig.get_config_vars('CCSHARED','CFLAGS') ['-pipe', '-fno-strict-aliasing -fno-common -dynamic -DNDEBUG -g -fwrapv -Os -Wall -Wstrict-prototypes -DENABLE_DTRACE -arch i386 -arch ppc -arch x86_64'] Notice the "-arch i386 -arch ppc -arch x86_64" that only exists under Snow Leopard. As stated earlier, it is this set of flags which the prefix gcc does not understand/accept. All of this correlates with a python Mach-O universal binary under snow leopard: $ /usr/bin/file /usr/bin/python /usr/bin/python: Mach-O universal binary with 3 architectures /usr/bin/python (for architecture x86_64): Mach-O 64-bit executable x86_64 /usr/bin/python (for architecture i386): Mach-O executable i386 /usr/bin/python (for architecture ppc7400): Mach-O executable ppc Under other versions of OSX python is a universal binary but has no 64-bit build. It is only ppc/i386. If someone were to build a module in 32-bit mode and then later boot into 64-bit mode then existing python scripts could stop working under snow leopard. The build process worked before but probably included the system frameworks (perhaps accidentally?) and still managed to work. Now that python is built incompatibly with a prefix build, this bug is showing up.
I went through the bootstrap process with another user on (a virgin) Snow Leopard yesterday/today and there was no such problem with Python. I think you try to tell me that it doesn't work for some reason, but I don't get it. What should be different in your case that other ~x86-macos and ~x64-macos users don't have?
hmm, seems that following the recipe in a more simple fashion does build python and complete bootstrapping correctly. I guess I'll be digging through my build process. Sorry for the bother.
