I've attached emerge --info, and the output from emerge --oneshot python and emerge --oneshot bintutils-apple (trying to downgrade to 3.1.2, which was working fine). Sorry for being so vague, but I don't really know how to describe the problem. I'm hoping the attached logs will be more helpful. An example (from emerge --oneshot python): libtool -o Python.framework/Versions/2.6/Python -dynamic libpyt hon2.6.a \ -lSystem -lSystemStubs -install_name /opt/gentoo/usr/li b/Python.framework/Versions/2.6/Python -compatibility_version 2.6 -current_versi on 2.6 ;\ fi terminate called after throwing an instance of 'char*' terminate called recursively libtool: fatal error in ld make: *** [Python.framework/Versions/2.6/Python] Error 1 Reproducible: Always
Created attachment 204062 [details] emerge --info
Created attachment 204063 [details] emerge --oneshot python
Created attachment 204064 [details] emerge --oneshot binutils-apple (downgrade to 3.1.2)
as 64-bits user you can't downgrade to 3.1.2 the 3.1.2-r1 ebuild was removed (but you can recover it from the attic), and I doubt whether its 64-bits patches are any better than the 3.2 sources. can you verify binutils-config properly selected the 3.2 compiler? (I guess I should have slotted this, sorry) on x64 leopard this worked magically fine, so I'll have to see for myself if I can reproduce the issue on snow leopard.
> can you verify binutils-config properly selected the 3.2 compiler? (I guess I > should have slotted this, sorry) ~ $ binutils-config -l [1] x86_64-apple-darwin10-3.2 * ~ $ ls -als /opt/gentoo/usr/bin/ld* 4 lrwxr-xr-x 1 josephgallo staff 24 2009-09-14 11:36 /opt/gentoo/usr/bin/ld -> x86_64-apple-darwin10-ld 4 lrwxr-xr-x 1 josephgallo staff 26 2009-09-14 11:36 /opt/gentoo/usr/bin/ld64 -> x86_64-apple-darwin10-ld64 Does this help? No need to apologize, I know I'm tracking something pretty unstable, and I expect there to be problems. That's part of the fun. :)
Interesting side note: I'm running an "emerge -e @system" and things are going fine so far (I'm on 24 of 67), so that makes me think that ld is actually fine, and maybe this is a problem with libtool as it is using ld? Of course, I'm just grasping at straws, and could be totally wrong.
libtool is part of cctools. binutils-apple consists of cctools + ld64. The latter component was left unchanged since 3.1.2, the former got bumped. So libtool could be different/problematic. Weird though because I thought others with x86-macos on snow leopard had no such problems.
I made it all the way through an emerge -e world, the only package that didn't build was python.
I nuked my prefix and reinstalled today, and didn't run into this. I think we can probably chalk it up to gremlins and mark this as "works for me" or "can't reproduce" or something.
black magic
I got this same issue off a clean bootstrap last night. I tried to check the binutils-config and got this: mbp:~ root# binutils-config /opt/gentoo/usr/bin/binutils-config: line 22: /opt/gentoo/etc/init.d/functions.sh: No such file or directory binutils-config: Could not source /opt/gentoo/etc/init.d/functions.sh! I remember seeing something about these files getting removed but don't recall where. I suppose I can try another emerge -e system for the heck of it ... The stuff about latest_tree vs. tree, is that still necessary?
no, but in your case the culprit it the latest portage, which I'll mask.
'kay. Remerged portage and baselayout. binutils is x86_64-apple-darwin10-3.2 which is the only one installed. Running the -e system now; it'll hit python soon. ... same failure. I'm going to dig in a little (not familiar with libtool, but there's not time like the present ...
Okay. It's trying to build both 32 and 64 bit libs: libtool -v -o Python.framework/Versions/2.6/Python -dynamic libpython2.6.a -lSystem -lSystemStubs -install_name /opt/gentoo/usr/lib/Python.framework/Versions/2.6/Python -compatibility_version 2.6 -current_version 2.6 + ld -arch_multiple -arch x86_64 -dylib -dynamic -all_load -force_cpusubtype_ALL -no_arch_warnings -dylib_compatibility_version 2.6 -dylib_current_version 2.6 -dylib_install_name /opt/gentoo/usr/lib/Python.framework/Versions/2.6/Python -ldylib1.o libpython2.6.a -lSystem -lSystemStubs -o Python.framework/Versions/2.6/Python.libtool.x86_64 -final_output Python.framework/Versions/2.6/Python + ld -arch_multiple -arch i386 -dylib -dynamic -all_load -force_cpusubtype_ALL -no_arch_warnings -dylib_compatibility_version 2.6 -dylib_current_version 2.6 -dylib_install_name /opt/gentoo/usr/lib/Python.framework/Versions/2.6/Python -ldylib1.o libpython2.6.a -lSystem -lSystemStubs -o Python.framework/Versions/2.6/Python.libtool.i386 -final_output Python.framework/Versions/2.6/Python terminate called after throwing an instance of 'char*' terminate called recursively libtool: fatal error in ld Adding to -arch_only x86_64 to libtool makes it generate only the 64 bit ld which succeeds and then python installs. Should libtool always use -arch_only as a default? The python build then gets further. Still looking into where it fails. It's not entirely clear, but it ends with this, so I'm wondering if it's related to the Qt message? Failed to find the necessary bits to build these modules: _bsddb bsddb185 dbm dl gdbm imageop linuxaudiodev ossaudiodev spwd sunaudiodev To find the necessary bits, look in setup.py in detect_modules() for the module's name. Failed to build these modules: _Qt running build_scripts creating build/scripts-2.6 copying and adjusting /opt/gentoo/var/tmp/portage/dev-lang/python-2.6.2-r01.4/work/Python-2.6.2/Tools/scripts/pydoc -> build/scripts-2.6 copying and adjusting /opt/gentoo/var/tmp/portage/dev-lang/python-2.6.2-r01.4/work/Python-2.6.2/Tools/scripts/idle -> build/scripts-2.6 copying and adjusting /opt/gentoo/var/tmp/portage/dev-lang/python-2.6.2-r01.4/work/Python-2.6.2/Tools/scripts/2to3 -> build/scripts-2.6 copying and adjusting /opt/gentoo/var/tmp/portage/dev-lang/python-2.6.2-r01.4/work/Python-2.6.2/Lib/smtpd.py -> build/scripts-2.6 changing mode of build/scripts-2.6/pydoc from 644 to 755 changing mode of build/scripts-2.6/idle from 644 to 755 changing mode of build/scripts-2.6/2to3 from 644 to 755 changing mode of build/scripts-2.6/smtpd.py from 644 to 755 make: *** [sharedmods] Error 1 * ERROR: dev-lang/python-2.6.2-r01.4 failed: * emake failed * * Call stack: * ebuild.sh: 51: <call call-ebuildshell 'src_compile'> * environment: 807: <call src_compile> * environment:4174: <call _eapi2_src_compile> * ebuild.sh: 700: emake || die "emake failed" * * If you need support, post the topmost build error, and the call stack if relevant. mbp:python root# I'd reopen this bug if I could ...
(Sorry about the "and then python installs" phrase: a little too much wishful thinking.)
It's dying trying to link Qt. Traced it as far as mbp:Python-2.6.2 root# /opt/gentoo/usr/bin/x86_64-apple-darwin10-ld -v -dynamic -arch x86_64 -bundle -macosx_version_min 10.6.0 -undefined dynamic_lookup -weak_reference_mismatches non-weak -undefined dynamic_lookup -o build/lib.macosx-10.6-i386-2.6/_Qt.bundle -lbundle1.o -L. -L/opt/gentoo/usr/lib/Python.framework/Versions/2.6/lib -L. -L/opt/gentoo/usr/lib/gcc/x86_64-apple-darwin10/4.2.1 -L/opt/gentoo/usr/lib/gcc/x86_64-apple-darwin10/4.2.1 -L/opt/gentoo/usr/lib/gcc/x86_64-apple-darwin10/4.2.1/../../../../x86_64-apple-darwin10/lib -L/opt/gentoo/usr/lib/gcc/x86_64-apple-darwin10/4.2.1/../../.. build/temp.macosx-10.6-i386-2.6/opt/gentoo/var/tmp/portage/dev-lang/python-2.6.2-r01.4/work/Python-2.6.2/Mac/Modules/qt/_Qtmodule.o -framework QuickTime -framework Carbon -lgcc_s.10.5 -lgcc -lSystem @(#)PROGRAM:ld PROJECT:ld64-85.2.1 (Gentoo binutils-apple-3.2) Library search paths: . /opt/gentoo/usr/lib/Python.framework/Versions/2.6/lib . /opt/gentoo/usr/lib/gcc/x86_64-apple-darwin10/4.2.1 /opt/gentoo/usr/lib/gcc/x86_64-apple-darwin10/4.2.1 /opt/gentoo/usr/x86_64-apple-darwin10/lib /opt/gentoo/usr/lib /opt/gentoo/usr/x86_64-apple-darwin10/lib/gcc /opt/gentoo/usr/x86_64-apple-darwin10/lib /opt/gentoo/usr/lib /opt/gentoo/lib /usr/lib /usr/local/lib Framework search paths: /Library/Frameworks/ /System/Library/Frameworks/ terminate called after throwing an instance of 'char const*' terminate called recursively Abort trap ... ah, running with the apple ld actually gives a message instead of the "throwing an instance of ": ld: warning: in /System/Library/Frameworks//QuickTime.framework/QuickTime, missing required architecture x86_64 in file which, on checking, is true. QuickTime is only ppc and x86. Which, actually, I remember hearing: QuickTime wasn't switched to 64bit, instead something new was added and there are places where they actually have to run 32 bit QT in a separate process. Do we just disable it? And on a seperate issue, something we can do to get a message from the prefix ld, instead of the "throw" message?
The ld problem should be a warning but is fatal because of (new) bug #286306. Python may well build after that (and fixing the libtool issue?) Not sure how much of the aqua stuff will work. See upstream http://bugs.python.org/issue6802. Upstream is trying to release 2.6.3, which has a number of 10.6 fixes. They talked about 25 Sept, but things have been quiet for a while with a few release blockers, so I'm not sure when it'll happen. But aside from the two issues here, I wonder how much we can do before they release ...
With #286306 fixed, this compiles as does upstream. Don't know if the quicktime stuff actually works, but that's a different issue ...
