When I am supposed to emerge portage, it fails while trying to emerge libperl. `sh cflags "optimize='-march=nocona'" toke.o` "-fPIC" toke.c CCCMD = x86_64-apple-darwin9-gcc -DPERL_CORE -c -fno-common -DPERL_DARWIN -no-cpp-precomp -fno-strict-aliasing -pipe -Wdeclaration-after-statement -march=nocona -Wall toke.c: In function 'S_scan_formline': toke.c:10542: error: invalid operands to binary + (have 'char *' and 'char *') toke.c:10542: error: lvalue required as unary '&' operand toke.c:10542: error: lvalue required as unary '&' operand {standard input}:unknown:Undefined local symbol LC16 {standard input}:unknown:Undefined local symbol LC212 make: *** [toke.o] Error 1 * ERROR: sys-devel/libperl-5.8.8-r2 failed: * Unable to make libperl.dylib I've tried using a custom ebuild that removes -DPERL_CORE and -DPERL_DARWIN, which gets me farther into the build, but then it fails in Makefile.SH on the $eunicefix line because $eunicefix is undefined. Removing that line gives me another error: CCCMD = -c -march=nocona /pfx/tmp/usr/bin/bash: -c: command not found Reproducible: Always Steps to Reproduce: 1. emerge libperl 2. 3. I'm bootstrapping prefix under Mac OS X Snow Leopard. I'm on a case-insensitive file system (I will try on case-sensitive soon). I can provide more info if needed, and am here to try your suggestions, since many don't have access to this build yet.
What step of what document are you on?
(In reply to comment #1) > What step of what document are you on? > Code 1.11 env FEATURES="-collision-protect" emerge --oneshot portage http://www.gentoo.org/proj/en/gentoo-alt/prefix/bootstrap-macos.xml
you're on Snow Leopard, why isn't your CHOST *-darwin10?
(In reply to comment #3) > you're on Snow Leopard, why isn't your CHOST *-darwin10? > Alright, I've grabbed the 10.6 profile from CVS, and now gcc-apple won't even compile. Maybe I should wait a bit before the profile and ebuilds get sorted out? ... nm: can't open file: .libs/compatibility.o (No such file or directory) lots of file not found errors of .libs/xxx.o where xxx.o is actually in cwd. .... nm error at /pfx/var/tmp/portage/sys-devel/gcc-apple-4.2.1_p5574/work/libstdcxx-16/libstdcxx/libstdc++-v3/scripts/make_exports.pl line 130.
you'll have to bootstrap using latest_tree, instead of tree that'll get you the profile and updates ebuilds
(In reply to comment #5) > you'll have to bootstrap using latest_tree, instead of tree > > that'll get you the profile and updates ebuilds > Thanks, now gcc compiles, but I'm right back to step 1. libperl fails in toke.c. With various sed replacements, it still fails later in the build.
I have the same problem on Snow Leopard with x86 (not x64). I tried bootstrapping using tree or latest_tree, and using the 10.5/x86 profile as well as a custom 10.6/x86 profile (largely the same but with CHOST ending with darwin10). bootstrap-prefix.sh r50036; portage prefix snapshot 20090829. In addition, perl apparently fails to detect my rand() function: Checking to see how many bits your rand() function produces... Configure: line 18013: try: command not found How many bits does your rand() function produce? (None of the answers appear to affect the later error.)
right, same thing everywhere. Need to find a fix for that.
Created attachment 202903 [details] Emerge log for libperl Interesting stuff going on at lines 144-165 or so, it looks like the problem might be related to ar not working right (/me is a newb, though, so don't bite, please.)
it builds if i add "-Dnm=/usr/bin/nm" to Configure so looks like this is binutils-apple issue (Configure tries with /opt/gentoo/usr/bin/nm if you don't specify -Dnm)
hmmm, aha, that's interesting. unfortunately 10.6's cctools and ld64 don't compile due to missing stuff :(
is that possible to use pre-compiled toolchain from osx?
this would mean 32-bits bootstraps would/should be ok
perl-5.8.9 fails too? can anyone try?
same error with 5.8.9: /opt/gentoo/usr/bin/nm didn't seem to work right. Trying /opt/gentoo/usr/bin/ar instead... ar: /usr/lib/libc.dylib: Inappropriate file type or format /opt/gentoo/usr/bin/ar didn't seem to work right. Maybe this is a Cray...trying bld instead... Configure: line 7587: bld: command not found Configure: line 7590: bld: command not found ar: /usr/lib/libdbm.dylib: Inappropriate file type or format Configure: line 7590: bld: command not found ar: /usr/lib/libdl.dylib: Inappropriate file type or format Configure: line 7590: bld: command not found ar: /usr/lib/libm.dylib: Inappropriate file type or format Configure: line 7590: bld: command not found ar: /usr/lib/libutil.dylib is a fat file (use libtool(1) or lipo(1) and ar(1) on it) ar: /usr/lib/libutil.dylib: Inappropriate file type or format and compilation fails with: toke.c: In function 'Perl_yylex': toke.c:5516: error: lvalue required as unary '&' operand toke.c:5516: error: lvalue required as unary '&' operand
also i was able to bootstrap system (with small python/perl patches for 10.6) using binutils symlinked from /usr (ie binaries from apple)
right, you can of course use native-cctools to use the system installed ld, ar, nm, etc. is there any log that can make it more clear why perl thinks nm isn't working right?
/opt/gentoo/usr/bin/nm /usr/lib/libc.dylib /opt/gentoo/usr/bin/nm: for architecture x86_64 object: /usr/lib/libc.dylib malformed object (unknown load command 5) btw, didn't saw native-cctools, thx! (i symlinked native binutils to try)
(In reply to comment #18) > /opt/gentoo/usr/bin/nm /usr/lib/libc.dylib > /opt/gentoo/usr/bin/nm: for architecture x86_64 object: /usr/lib/libc.dylib > malformed object (unknown load command 5) I still suspect (and the above log appears to confirm this) that nm is expecting a binary segment, and getting a Universal Binary (i.e. multiple segments). AFAICT, the ebuild removes UB support from apple-cctools. Either use a UB-aware nm, or run libtool or lipo first.
how does the ebuild remove FAT binary support?
(In reply to comment #20) > how does the ebuild remove FAT binary support? Well, that's how I interpreted this comment from binutils-apple-3.1.2-r1.ebuild: # we don't do universal binaries ((++c)); rm -rf blank-stubs; I see now that that's apparently only for ld, though, not ar.
FYI bigger part of output: Where is your C library? [/usr/lib/libc.dylib] Extracting names from the following files for later perusal: /usr/lib/libc.dylib /usr/lib/libdbm.dylib /usr/lib/libdl.dylib /usr/lib/libm.dylib /usr/lib/libutil.dylib This may take a while................../opt/gentoo/usr/bin/nm didn't seem to work right. Trying /opt/gentoo/usr/bin/ar instead... ar: /usr/lib/libc.dylib is a fat file (use libtool(1) or lipo(1) and ar(1) on it) ar: /usr/lib/libc.dylib: Inappropriate file type or format /opt/gentoo/usr/bin/ar didn't seem to work right. Maybe this is a Cray...trying bld instead... Configure: line 7392: bld: command not found Configure: line 7395: bld: command not found ar: /usr/lib/libdbm.dylib: Inappropriate file type or format Configure: line 7395: bld: command not found ar: /usr/lib/libdl.dylib is a fat file (use libtool(1) or lipo(1) and ar(1) on it) ar: /usr/lib/libdl.dylib: Inappropriate file type or format Configure: line 7395: bld: command not found ar: /usr/lib/libm.dylib is a fat file (use libtool(1) or lipo(1) and ar(1) on it) ar: /usr/lib/libm.dylib: Inappropriate file type or format Configure: line 7395: bld: command not found ar: /usr/lib/libutil.dylib: Inappropriate file type or format
libc.dylib: file /usr/lib/libSystem.B.dylib: /usr/lib/libSystem.B.dylib: Mach-O fat file with 3 architectures
I do not exclude my 64-bits patching to binutils-apple to broke nm. Maybe because your libs only contain 3 arches, and on leopard 4 the problem only now gets noticed (alignment issues). I think this is not so much a problem with perl, but with our nm :(
python broken too: .... ranlib: archive member: libpython2.6.a(threadmodule.o) offset in archive not a multiple of 8 (must be since member is an 64-bit object file) x86_64-apple-darwin10-ranlib libpython2.6.a /opt/gentoo/usr/bin/install -c -d -m 755 Python.framework/Versions/2.6 if test ""; then \ x86_64-apple-darwin10-gcc -o Python.framework/Versions/2.6/Python -dynamiclib \ -isysroot "" \ -all_load libpython2.6.a -Wl,-single_module \ -install_name /opt/gentoo/usr/lib/Python.framework/Versions/2.6/Python \ -compatibility_version 2.6 \ -current_version 2.6; \ else \ libtool -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 ;\ fi libtool: for architecture x86_64 object: /usr/lib/libSystem.dylib malformed object (unknown load command 5) libtool: for architecture: (null) file: -lSystem is not an object file (not allowed in a library) libtool: for architecture i386 object: /usr/lib/libSystem.dylib malformed object (unknown load command 5) make: *** [Python.framework/Versions/2.6/Python] Error 1
right, that clearly indicates an offset problem, as load_commands are right in the Mach-O header, and differ for 32-bits and 64-bits objects.
Another option which sounds much more plausible to me is that the linker is too old. Apple added a new load_command, put that in the object, and since we have the leopard linker here it doesn't know this load_command and complains. problem is that I can't compile the linker sources since Apple forgot to include something (libunwind, Apple style). perhaps native-cctools is the only solution for the moment.
maybe it's possible to get plain libunwind from gnu gcc?
If only that was /it/. Apple uses something that has includes like this <libunwind/[A-Z][a-z]+>, see http://www.opensource.apple.com/source/ld64/ld64-95.2.12/src/ld/MachOReaderRelocatable.hpp, for instance: #include <libunwind/DwarfInstructions.hpp> now I can't find such file anywhere, but if you have clues/ideas, let me know!
good news: binutils-apple-3.2 provides a nm that works correctly. I excluded ld64 from SN in that build, hopefully we can add it somewhere in the future.
binutils-apple-3.2 is unmasked now, and fixes this particular bootstrap problem (the next is openssh :()
