ld64 sometimes builds wrong which causes other software to fail to build

[jwhowse4]

I am running Lion 10.7.4 and Xcode 4.4.1. After the recent upgrade of ld64 to 133.3 I received the following compile error using gcc46 on a piece of my own code.

ld: warning: ignoring file main_bst_ddkc_sup_tf.o, file was built for unsupported file format ( 0xcf 0xfa 0xed 0xfe 0x 7 0x 0 0x 0 0x 1 0x 3 0x 0 0x 0 0x 0 0x 1 0x 0 0x 0 0x 0 ) which is not the architecture being linked (x86_64): main_bst_ddkc_sup_tf.o
ld: file is universal (2 slices) but does not contain a(n) x86_64 slice: /usr/lib/crt1.10.5.o for architecture x86_64
collect2: ld returned 1 exit status
make: *** [sup_tf_ddkc] Error 1

This same code had compiled prior to the ld64 update.

So I tried recompiling the gcc46 port and it failed leaving the attached log file. I then tried replacing the linker ld from the ld64 port with the apple linker from Xcode 4.4.1 and the gcc46 port compiled just fine. Furthermore this new gcc46 compiled my code without the above error.

Additionally since the ld64 port upgrade the pgplot port with the +gcc46 option has failed to compile leaving the attached log file.

In short I suspect there is something wrong with the current ld64 port, but I am not sure how to fix it. Any help would be appreciated.

[jwhowse4]

gcc46 failure log

[jwhowse4]

pgplot failure log

[jeremyhu (Jeremy Huddleston Sequoia)]

I then tried replacing the linker ld from the ld64 port with the apple linker from Xcode 4.4.1

Can you please tell me *precisely* what you did here since there is actually a lot more room for ambiguity in that statement than you realize.

What is the output of?

/path/to/ld -v

Where /path/to/ld is the "updated" ld that you replaced.

[jeremyhu (Jeremy Huddleston Sequoia)]

Also, can you please provide a reduced test case to show off the issue and attach the object file you are having trouble with?

[jwhowse4]

Replying to jeremyhu@…:

I then tried replacing the linker ld from the ld64 port with the apple linker from Xcode 4.4.1

Can you please tell me *precisely* what you did here since there is actually a lot more room for ambiguity in that statement than you realize.

What is the output of?

/path/to/ld -v

Where /path/to/ld is the "updated" ld that you replaced.

In the directory /opt/macports/bin (which is where I put MacPorts) I ran the following commands.

mv ld ld.macports
ln -s /usr/bin/ld ld

Now the command /opt/macports/bin/ld -v gives

@(#)PROGRAM:ld  PROJECT:ld64-133.3
configured to support archs: armv6 armv7 i386 x86_64
LTO support using: LLVM version 3.1svn, from Apple Clang 4.0 (build 421.0.60)

[jwhowse4]

Replying to jeremyhu@…:

Also, can you please provide a reduced test case to show off the issue and attach the object file you are having trouble with?

I am not sure what you are asking for here. One example however is the fact that using the xcode linker /usr/bin/ld the port pgplot with the +gcc46 option compiles successfully rather than generating the error log which I previously attached.

[jeremyhu (Jeremy Huddleston Sequoia)]

What I am asking for is a reduced case of this bug. Provide a sample source file (and the object file created by gcc46) which shows this issue.

[jwhowse4]

Replying to jeremyhu@…:

What I am asking for is a reduced case of this bug. Provide a sample source file (and the object file created by gcc46) which shows this issue.

It sounds as if you are asking for an example of a single simple source file for which this problem occurs. I do not have such an example. I have seen changing from the latest macports linker to the apple linker eliminate compilation failure in three cases. First, one of my own code projects which involves multiple source files. Second, the macports package pgplot. Third, the macports package gcc46. If you would like my code project I may be able to send it to you, but it is probably not what you are looking for.

[jeremyhu (Jeremy Huddleston Sequoia)]

Ok, I thought your project might be a simpler example than pgplot.

The version you replaced ld with is essentially the same version, so it's probably a build setting or an external dependency that is out of whack. I'll look into it soon. If you find an example that is simpler than pgplot, please do let me know.

[jwhowse4]

I found a very simple example which reproduces the problem. However the problem is not what I thought. Use the following C program.

#include <stdio.h>
#include <stdlib.h>
#include <math.h>

int main()
{
  int    i;
  double x;

  for( i = 0; i < 5; i++ )
    {
      x = sqrt( (double) i );
      printf( "%lf\n", x );
    }

  return 0;
}

Compile and then link this program using the XCode 4.4.1 linker provided by Apple. The result is the executable is created and functions properly.

# Make the linker the xcode 4.4.1 linker in /usr/bin
cp /opt/macports/ld.apple /opt/macports/ld
# Compile the code to an object file
gcc-mp-4.6 -c test.c
# Link the object file to an executable
gcc-mp-4.6 -o TstPrg test.o -lm
# Check existence of executable
ls TstPrg
TstPrg
# Executable DOES EXIST.  It also runs properly.

Compile and then link this program using the linker provided by the MacPorts package ld64. The result is the executable is NOT created at all.

# Make the linker the macports linker in port ld64
cp /opt/macports/ld.macports /opt/macports/ld
# Compile the code to an object file
gcc-mp-4.6 -c test.c
# Link the object file to an executable
gcc-mp-4.6 -o TstPrg test.o -lm
ld: warning: ignoring file test.o, file was built for unsupported file format ( 0xcf 0xfa 0xed 0xfe 0x 7 0x 0 0x 0 0x 1 0x 3 0x 0 0x 0 0x 0 0x 1 0x 0 0x 0 0x 0 ) which is not the architecture being linked (x86_64): test.o
ld: file is universal (2 slices) but does not contain a(n) x86_64 slice: /usr/lib/crt1.10.5.o for architecture x86_64
collect2: ld returned 1 exit status
# Check existence of executable
ls TstPrg
ls: TstPrg: No such file or directory
# Executable DOES NOT EXIST

The object files test.o created by these two procedures are identical. The problem apparently is that on my system the MacPorts ld64 linker is refusing to create executables from object files. I have attached by object files and the successfully created executable.

[jwhowse4]

Object file using Apple linker

[jwhowse4]

Object file using MacPorts linker

[jwhowse4]

Executable using Apple linker

[jeremyhu (Jeremy Huddleston Sequoia)]

Right. The linker doesn't create object files. It combines them into an executable. It's expected that the object files would be exactly the same.

[ryandesign (Ryan Carsten Schmidt)]

I am also under the impression that having the current version of the ld64 port installed is causing various problems for other software. See #36068 for a problem with wine-devel which appears to be similar to the above:

ld: file is universal (2 slices) but does not contain a(n) i386 slice: /usr/lib/crt1.10.6.o for architecture i386

I myself am unable to upgrade apple-gcc42 today, seeing errors like this:

ld: warning: ignoring file libgcc/./_negdi2_s.o, file was built for unsupported file format ( 0xcf 0xfa 0xed 0xfe 0x 7 0x 0 0x 0 0x 1 0x 3 0x 0 0x 0 0x 0 0x 1 0x 0 0x 0 0x 0 ) which is not the architecture being linked (x86_64): libgcc/./_negdi2_s.o
ld: warning: ignoring file libgcc/./_muldi3_s.o, file was built for unsupported file format ( 0xcf 0xfa 0xed 0xfe 0x 7 0x 0 0x 0 0x 1 0x 3 0x 0 0x 0 0x 0 0x 1 0x 0 0x 0 0x 0 ) which is not the architecture being linked (x86_64): libgcc/./_muldi3_s.o

I do have ld64 installed universal if that matters, and I'm on Mountain Lion.

[jwhowse4]

I have the ports gcc45, gcc46 and gcc47 installed. None of them successfully create executables for any program I have tried since the ld64 port update.

[jwhowse4]

Replying to ryandesign@…:

I am also under the impression that having the current version of the ld64 port installed is causing various problems for other software. See #36068 for a problem with wine-devel which appears to be similar to the above:

ld: file is universal (2 slices) but does not contain a(n) i386 slice: /usr/lib/crt1.10.6.o for architecture i386

I myself am unable to upgrade apple-gcc42 today, seeing errors like this:

ld: warning: ignoring file libgcc/./_negdi2_s.o, file was built for unsupported file format ( 0xcf 0xfa 0xed 0xfe 0x 7 0x 0 0x 0 0x 1 0x 3 0x 0 0x 0 0x 0 0x 1 0x 0 0x 0 0x 0 ) which is not the architecture being linked (x86_64): libgcc/./_negdi2_s.o
ld: warning: ignoring file libgcc/./_muldi3_s.o, file was built for unsupported file format ( 0xcf 0xfa 0xed 0xfe 0x 7 0x 0 0x 0 0x 1 0x 3 0x 0 0x 0 0x 0 0x 1 0x 0 0x 0 0x 0 ) which is not the architecture being linked (x86_64): libgcc/./_muldi3_s.o

I do have ld64 installed universal if that matters, and I'm on Mountain Lion.

I got the same errors under Lion with a non-universal install of ld64

[mf2k (Frank Schima)]

Replying to jwhowse4@…:

I have the ports gcc45, gcc46 and gcc47 installed. None of them successfully create executables for any program I have tried since the ld64 port update.

I had a similar strange problem with not being able to create C executables which was tracked down to the ld64 port. See #36068. My solution was to force uninstall and then re-install ld64. I suggest you try that. HTH.

[jwhowse4]

Replying to macsforever2000@…:

Replying to jwhowse4@…:

I have the ports gcc45, gcc46 and gcc47 installed. None of them successfully create executables for any program I have tried since the ld64 port update.

I had a similar strange problem with not being able to create C executables which was tracked down to the ld64 port. See #36068. My solution was to force uninstall and then re-install ld64. I suggest you try that. HTH.

I have already tried uninstalling and reinstalling ld64, unfortunately that solution does not work for me.

[jeremyhu (Jeremy Huddleston Sequoia)]

I just rebuilt all of gcc4[345678] with the new ld64 in place, and they were able to build/link test applications just fine.

The object file you provided above links just fine and produces an executable which prints:

0.000000
1.000000
1.414214
1.732051
2.000000

Based on comment:14, I've revbumped ld64 to force it to rebuild. cctools-headers and dyld-headers were pushed to svn after ld64 which would explain why I was not able to reproduce it but someone who built within that sliver of time would. Sorry for that.

I'm assuming that you rebuild ld64 without first syncing and upgrading the headers as the reason why you didn't report success in comment:15.

r97646

[jwhowse4]

Replying to jeremyhu@…:

I just rebuilt all of gcc4[345678] with the new ld64 in place, and they were able to build/link test applications just fine.

The object file you provided above links just fine and produces an executable which prints:

0.000000
1.000000
1.414214
1.732051
2.000000

Based on comment:14, I've revbumped ld64 to force it to rebuild. cctools-headers and dyld-headers were pushed to svn after ld64 which would explain why I was not able to reproduce it but someone who built within that sliver of time would. Sorry for that.

I'm assuming that you rebuild ld64 without first syncing and upgrading the headers as the reason why you didn't report success in comment:15.

r97646

Unfortunately this solution does not work for me. My attempt to link my simple code with the reinstalled ld64 linker gives the following error message. I have tried uninstalling and reinstalling all the explicit dependencies of ld64 as well as ld64 with the same negative result. Do you have any other suggestions?

gcc-mp-4.6 -o TstPrg test.o -lm
ld: warning: ignoring file test.o, file was built for unsupported file format ( 0xcf 0xfa 0xed 0xfe 0x 7 0x 0 0x 0 0x 1 0x 3 0x 0 0x 0 0x 0 0x 1 0x 0 0x 0 0x 0 ) which is not the architecture being linked (x86_64): test.o
ld: file is universal (2 slices) but does not contain a(n) x86_64 slice: /usr/lib/crt1.10.5.o for architecture x86_64
collect2: ld returned 1 exit status

[seongmin.hwang+macports@…]

Cc Me!

[jeremyhu (Jeremy Huddleston Sequoia)]

Has dupe #36099

Please do:

sudo port -v sync
sudo port -v -f uninstall cctools cctools-headers dyld-headers ld64
sudo port -v install cctools

I just want to make sure you really have the latest versions of things... buildbot is building this fine; I'm building this fine. There must be something about your config which is different...

[rob.patro@…]

I'm encountering the same issue and have tried cleaning the current ports via these installed commands. Is there a way to check what version of ld64 I'm getting (to see if it's what I should be getting).

[update: I definitely have the correct revision of ld64, and I'm getting the same errors as jwhowse4. Could it be a Mountain Lion-specific issue?]

[rob.patro@…]

Cc Me!

[jwhowse4]

Replying to jeremyhu@…:

Has dupe #36099

Please do:

sudo port -v sync
sudo port -v -f uninstall cctools cctools-headers dyld-headers ld64
sudo port -v install cctools

I just want to make sure you really have the latest versions of things... buildbot is building this fine; I'm building this fine. There must be something about your config which is different...

This is what I did last night using a different set of commands, I also uninstalled and reinstalled libunwind-headers. I will run exactly this set of commands tonight, but at this point I doubt it will fix the problem. What OS and XCode version are you running? I am wondering if this is an XCode 4.4.1 issue.

[jwhowse4]

Replying to rob.patro@…:

I'm encountering the same issue and have tried cleaning the current ports via these installed commands. Is there a way to check what version of ld64 I'm getting (to see if it's what I should be getting).

[update: I definitely have the correct revision of ld64, and I'm getting the same errors as jwhowse4. Could it be a Mountain Lion-specific issue?]

I am running Lion not Mountain Lion. What XCode version are you running?

[jeremyhu (Jeremy Huddleston Sequoia)]

I've had success on:

10.5.8 w/ 3.1.4 i386 x86_64 ppc
10.6.8 w/ 3.2.6 i386 x86_64
10.8.1 w/ 4.4.1 x86_64

I have not tried 10.7.x

[rob.patro@…]

Replying to jeremyhu@…:

I've had success on:

10.5.8 w/ 3.1.4 i386 x86_64 ppc
10.6.8 w/ 3.2.6 i386 x86_64
10.8.1 w/ 4.4.1 x86_64

I have not tried 10.7.x

Hi Jeremy,

I've had (somewhat) of a success now. By uninstalling and reinstalling the libunwind-headers, I was able to get gcc47 to properly compile.

However, now, it seems to have a problem finding a number of symbols from the standard library. For example, it can't find the std::string move constructor:

Undefined symbols for architecture x86_64:
  "std::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string(std::basic_string<char, std::char_traits<char>, std::allocator<char> >&&)"

Any ideas if this is occurring for you or how to fix it?

[jwhowse4]

Replying to jwhowse4@…:

Replying to jeremyhu@…:

Has dupe #36099

Please do:

sudo port -v sync
sudo port -v -f uninstall cctools cctools-headers dyld-headers ld64
sudo port -v install cctools

I just want to make sure you really have the latest versions of things... buildbot is building this fine; I'm building this fine. There must be something about your config which is different...

This is what I did last night using a different set of commands, I also uninstalled and reinstalled libunwind-headers. I will run exactly this set of commands tonight, but at this point I doubt it will fix the problem. What OS and XCode version are you running? I am wondering if this is an XCode 4.4.1 issue.

I ran these commands and added libunwind-headers. The result is still a linker which refuses to create executables. I tried upgrading gcc45, gcc46 and gcc47 with the newly installed linker and all three ports fail to compile. I have attached the resulting log files. Any suggestions at this point?

[jwhowse4]

At the moment I am unable to attach files to this ticket. I will try again later.

 Trac detected an internal error:
OSError: [Errno 13] Permission denied: '/var/trac/env/macports/attachments/ticket/36026/gcc47_main.log'

[ralph@…]

For what its worth, I am seeing this problem too, and also with the apple-gcc4.2 port. I'm using an XCode 4.5 prerelease, so am not expecting sympathy particularly, but just noting something is definitely amiss - it's not just one person's setup.

[ralph@…]

Trying to rebuild llvm-3.1 ended up with this result:

llvm[1]: Linking Release+Debug+Asserts Shared Library libLLVM-3.1.dylib
/usr/bin/clang++ -I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_llvm-3.1/llvm-3.1/work/llvm-3.1.src/include -I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_llvm-3.1/llvm-3.1/work/llvm-3.1.src/tools/llvm-shlib  -D_DEBUG -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -O3  -g -fvisibility-inlines-hidden -fno-exceptions -fno-rtti -fno-common -Woverloaded-virtual -Wcast-qual  -O3 -g -Wl,-rpath -Wl,@executable_path/../lib -L/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_llvm-3.1/llvm-3.1/work/llvm-3.1.src/Release+Debug+Asserts/lib -L/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_llvm-3.1/llvm-3.1/work/llvm-3.1.src/Release+Debug+Asserts/lib -arch x86_64 -arch x86_64 -m64  -pedantic -Wno-long-long -Wall -W -Wno-unused-parameter -Wwrite-strings  -Wcovered-switch-default  -dynamiclib -mmacosx-version-min=10.8 -o /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_llvm-3.1/llvm-3.1/work/llvm-3.1.src/Release+Debug+Asserts/lib/libLLVM-3.1.dylib  \
	   -lLLVMARMAsmParser -lLLVMARMAsmPrinter -lLLVMARMCodeGen -lLLVMARMDesc -lLLVMARMDisassembler -lLLVMARMInfo -lLLVMAnalysis -lLLVMArchive -lLLVMAsmParser -lLLVMAsmPrinter -lLLVMBitReader -lLLVMBitWriter -lLLVMCellSPUCodeGen -lLLVMCellSPUDesc -lLLVMCellSPUInfo -lLLVMCodeGen -lLLVMCore -lLLVMCppBackendCodeGen -lLLVMCppBackendInfo -lLLVMDebugInfo -lLLVMExecutionEngine -lLLVMHexagonAsmPrinter -lLLVMHexagonCodeGen -lLLVMHexagonDesc -lLLVMHexagonInfo -lLLVMInstCombine -lLLVMInstrumentation -lLLVMInterpreter -lLLVMJIT -lLLVMLinker -lLLVMMBlazeAsmParser -lLLVMMBlazeAsmPrinter -lLLVMMBlazeCodeGen -lLLVMMBlazeDesc -lLLVMMBlazeDisassembler -lLLVMMBlazeInfo -lLLVMMC -lLLVMMCDisassembler -lLLVMMCJIT -lLLVMMCParser -lLLVMMSP430AsmPrinter -lLLVMMSP430CodeGen -lLLVMMSP430Desc -lLLVMMSP430Info -lLLVMMipsAsmParser -lLLVMMipsAsmPrinter -lLLVMMipsCodeGen -lLLVMMipsDesc -lLLVMMipsDisassembler -lLLVMMipsInfo -lLLVMObject -lLLVMPTXAsmPrinter -lLLVMPTXCodeGen -lLLVMPTXDesc -lLLVMPTXInfo -lLLVMPowerPCAsmPrinter -lLLVMPowerPCCodeGen -lLLVMPowerPCDesc -lLLVMPowerPCInfo -lLLVMRuntimeDyld -lLLVMScalarOpts -lLLVMSelectionDAG -lLLVMSparcCodeGen -lLLVMSparcDesc -lLLVMSparcInfo -lLLVMSupport -lLLVMTarget -lLLVMTransformUtils -lLLVMVectorize -lLLVMX86AsmParser -lLLVMX86AsmPrinter -lLLVMX86CodeGen -lLLVMX86Desc -lLLVMX86Disassembler -lLLVMX86Info -lLLVMX86Utils -lLLVMXCoreCodeGen -lLLVMXCoreDesc -lLLVMXCoreInfo -lLLVMipa -lLLVMipo -all_load -Wl,-dead_strip -Wl,-seg1addr -Wl,0xE0000000  -Wl,-install_name -Wl,"@executable_path/../lib/libLLVM-3.1.dylib" -lpthread -lffi -lm 
ld: warning: no bits should be set in UNWIND_PERSONALITY_MASK of compact unwind encoding in __LD,__compact_unwind section
ld: warning: no bits should be set in UNWIND_PERSONALITY_MASK of compact unwind encoding in __LD,__compact_unwind section
ld: warning: no bits should be set in UNWIND_PERSONALITY_MASK of compact unwind encoding in __LD,__compact_unwind section
ld: in /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_llvm-3.1/llvm-3.1/work/llvm-3.1.src/Release+Debug+Asserts/lib/libLLVMMipsCodeGen.a(MipsSelectionDAGInfo.o), malformed __eh_frame section: FDE points to CIE outside __eh_frame section for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

[jeremyhu (Jeremy Huddleston Sequoia)]

I wish I could reproduce this. That would help me figure out the problem, but I haven't seen it on even my machines which are 100% external (no Apple Internal bits). I'm sorry, but I'm stumped =/

[jwhowse4]

Replying to jeremyhu@…:

I wish I could reproduce this. That would help me figure out the problem, but I haven't seen it on even my machines which are 100% external (no Apple Internal bits). I'm sorry, but I'm stumped =/

I have seen several errors similar to the following.

ld: file is universal (2 slices) but does not contain a(n) x86_64 slice: /usr/lib/crt1.10.5.o for architecture x86_64

This suggests to me that perhaps ld64 is mistaking Lion (10.7) for Leopard (10.5) at least on my system. How does the linker determine the system OS?

[jeremyhu (Jeremy Huddleston Sequoia)]

Has dupe #36122

[daniel@…]

Cc Me!

[ryandesign (Ryan Carsten Schmidt)]

Replying to jwhowse4@…:

I have seen several errors similar to the following.

ld: file is universal (2 slices) but does not contain a(n) x86_64 slice: /usr/lib/crt1.10.5.o for architecture x86_64

I have too, on Mountain Lion.

This suggests to me that perhaps ld64 is mistaking Lion (10.7) for Leopard (10.5) at least on my system.

No, I don't think it suggests that. Even on Mountain Lion, there only exists a crt1.10.5.o and a crt1.10.6.o in that directory. lipo confirms that they contain both expected architectures:

$ lipo -info /usr/lib/crt1.10*
Architectures in the fat file: /usr/lib/crt1.10.5.o are: i386 x86_64 
Architectures in the fat file: /usr/lib/crt1.10.6.o are: i386 x86_64 

So the error message suggests to me that there is a problem with ld64 determining the file's architecture.

[jstrane@…]

Cc Me!

[piotr@…]

Cc Me!

[jeremyhu (Jeremy Huddleston Sequoia)]

Does rebuilding ld64 after updating to the newer libunwind-headers address it? I can't really see what might be different on my system than yours... =/

[ralph@…]

I just installed the GM Seed for XCode 4.5, plus its new command line tools, and the problem seems to have gone away for me, but I'll report back if I see further issues.

[jeremyhu (Jeremy Huddleston Sequoia)]

Replying to ralph@…:

I just installed the GM Seed for XCode 4.5, plus its new command line tools, and the problem seems to have gone away for me, but I'll report back if I see further issues.

What ports did you rebuild anything after updating XCode? I want to narrow down what a cause might be, and know what set of ports you changed would certainly help.

Did you rebuild ld64 with the new libunwind-headers I just pushed?

[jwhowse4]

Replying to ryandesign@…:

Replying to jwhowse4@…:

I have seen several errors similar to the following.

ld: file is universal (2 slices) but does not contain a(n) x86_64 slice: /usr/lib/crt1.10.5.o for architecture x86_64

I have too, on Mountain Lion.

This suggests to me that perhaps ld64 is mistaking Lion (10.7) for Leopard (10.5) at least on my system.

No, I don't think it suggests that. Even on Mountain Lion, there only exists a crt1.10.5.o and a crt1.10.6.o in that directory. lipo confirms that they contain both expected architectures:

$ lipo -info /usr/lib/crt1.10*
Architectures in the fat file: /usr/lib/crt1.10.5.o are: i386 x86_64 
Architectures in the fat file: /usr/lib/crt1.10.6.o are: i386 x86_64 

So the error message suggests to me that there is a problem with ld64 determining the file's architecture.

I do not know anything about Mountain Lion but on Lion there are 3 files in /usr/lib with the prefix crt1.

lipo -info /usr/lib/crt1.*
Architectures in the fat file: /usr/lib/crt1.10.5.o are: x86_64 i386 
Architectures in the fat file: /usr/lib/crt1.10.6.o are: x86_64 i386 
Architectures in the fat file: /usr/lib/crt1.o are: x86_64 i386 

I do not understand why the linker is looking at crt1.10.5.o rather than crt1.o.

[ralph@…]

Hmm, maybe XCode 4.5 is not a full solution.. apple-gcc42 built OK, but libstdcxx-4.7.1_100 did not, ending with a report that "ld: symbol(s) not found for architecture x86_64".

The following ports apparently built OK, in this order, after installing XCode 4.5:

llvm-3.1-3.1_3

ld64-133.3_1

cctools-829_1+llvm31

apple-gcc42 @5666.3_7

swi-prolog-6.2.1_0+mt

I then did a selfupdate and the following built OK

libunwind-headers @35.1_0

ld64-133.3_2+llvm31

but libstdcxx-4.7.1_100 fell over.

[jwhowse4]

Replying to jeremyhu@…:

Did you rebuild ld64 with the new libunwind-headers I just pushed?

I rebuilt ld64 with the new libunwind-headers and this did not fix my problem, sigh...

[ralph@…]

I also rebuilt (successfully) all the items that libstdcxx depends upon, and tried rebuilding libstdcxx, but still no good.

[ralph@…]

libstdcxx-4.7.1_101 is no better

[jeremyhu (Jeremy Huddleston Sequoia)]

libstdcxx is not the problem. ld64 is.

[hapaguy (Brian Kurt Fujikawa)]

Cc Me!

[jstrane@…]

Cc Me!

[jwhowse4]

As an experiment I created a new MacPorts installation in addition to my existing one. I did this in order to obtain a fresh MacPorts installation with no other packages installed. I then performed the following two experiments.

EXPERIMENT #1

tar xvjf MacPorts-2.1.2.tar.bz2
cd MacPorts-2.1.2
setenv PATH /usr/bin:/usr/sbin:/bin:/sbin:/usr/X11/bin:/usr/texbin
./configure --prefix=/opt/macports-test --with-applications-dir=/opt/macports-test
make
make install
setenv PATH /opt/macports-test/bin:/opt/macports-test/sbin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/X11/bin:/usr/texbin
port -v selfupdate
port -v install libffi
port -v install llvm_select
port -v install cctools-headers
port -v install dyld-headers
port -v install libunwind-headers
port -v install perl5 +perl5_12
port -v install llvm-3.1
port -v install ld64 +llvm31

The linker ld from experiment #1 successfully creates executables for my example program using the gcc46 from my original MacPorts installation. I then removed the entire directory macports-test and performed the second experiment.

EXPERIMENT #2

tar xvjf MacPorts-2.1.2.tar.bz2
cd MacPorts-2.1.2
setenv PATH /usr/bin:/usr/sbin:/bin:/sbin:/usr/X11/bin:/usr/texbin
./configure --prefix=/opt/macports-test --with-applications-dir=/opt/macports-test
make
make install
setenv PATH /opt/macports-test/bin:/opt/macports-test/sbin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/X11/bin:/usr/texbin
port -v selfupdate
port -v install perl5 +perl5_12
port -v install libffi
port -v install llvm_select
port -v install cctools-headers
port -v install dyld-headers
port -v install libunwind-headers
port -v install llvm-3.1
port -v install ld64 +llvm31

The linker ld from experiment #2 fails to create executables for my example program using the gcc46 from my original MacPorts installation with the following familiar error message.

ld: warning: ignoring file test.o, file was built for unsupported file format ( 0xcf 0xfa 0xed 0xfe 0x 7 0x 0 0x 0 0x 1 0x 3 0x 0 0x 0 0x 0 0x 1 0x 0 0x 0 0x 0 ) which is not the architecture being linked (x86_64): test.o
ld: file is universal (2 slices) but does not contain a(n) x86_64 slice: /usr/lib/crt1.10.5.o for architecture x86_64
collect2: ld returned 1 exit status

I have no idea why this seemingly minor change in the order in which packages are installed changes the outcome, but I have attached the linkers generated by these two experiments in the hope that they will be useful. If you need any other information, please let me know.

[jwhowse4]

Linker created by Experiment #1

[jwhowse4]

Linker created by Experiment #2

[jeremyhu (Jeremy Huddleston Sequoia)]

Thanks ... so essentially changing when in your order you built perl5 had some impact on this.

Do you have the binpkgs available from both installs? I'm curious if you can try to figure out exactly what the difference is *before* ld64. ie, compare all of the other built packages to see what is different in them.

Can you try additional experiments to figure out a single reorder (ie: a jump forward by 1 rather than a jump forward by 5)?

I'll give your experiment a try later, but my plate is full with some other stuff at the moment. You are certainly on the right track, and thanks for these data, they're a big help!

[jeremyhu (Jeremy Huddleston Sequoia)]

I've kicked off a script to do a bunch of builds based on the data from your comment. Hopefully it'll be able to reproduce the issue and let me hone in a bit on the problem... I should be able to look at the results tomorrow. Thanks again.

[jeremyhu (Jeremy Huddleston Sequoia)]

A quick check comparing 'strings' on the two shows:

--- ld.mp.exp1.strings	2012-09-15 20:00:25.000000000 -0700
+++ ld.mp.exp2.strings	2012-09-15 20:00:30.000000000 -0700
@@ -548,56 +548,41 @@ N2ld4tool12PageZeroAtomE
 N2ld4tool13DSOHandleAtomE
 N2ld4tool14DataInCodeAtomI3armEE
 N2ld4tool14DataInCodeAtomI3x86EE
-N2ld4tool14DataInCodeAtomI6x86_64EE
 N2ld4tool14ExportInfoAtomI3armEE
 N2ld4tool14ExportInfoAtomI3x86EE
-N2ld4tool14ExportInfoAtomI6x86_64EE
 N2ld4tool14RebaseInfoAtomI3armEE
 N2ld4tool14RebaseInfoAtomI3x86EE
-N2ld4tool14RebaseInfoAtomI6x86_64EE
 N2ld4tool14StringPoolAtomE
 N2ld4tool15BindingInfoAtomI3armEE
 N2ld4tool15BindingInfoAtomI3x86EE
-N2ld4tool15BindingInfoAtomI6x86_64EE
 N2ld4tool15CustomStackAtomE
 N2ld4tool15DependentDRAtomI3armEE
 N2ld4tool15DependentDRAtomI3x86EE
-N2ld4tool15DependentDRAtomI6x86_64EE
 N2ld4tool15SymbolTableAtomI3armEE
 N2ld4tool15SymbolTableAtomI3x86EE
-N2ld4tool15SymbolTableAtomI6x86_64EE
 N2ld4tool16SplitSegInfoAtomI3armEE
 N2ld4tool16SplitSegInfoAtomI3x86EE
-N2ld4tool16SplitSegInfoAtomI6x86_64EE
 N2ld4tool18FunctionStartsAtomI3armEE
 N2ld4tool18FunctionStartsAtomI3x86EE
-N2ld4tool18FunctionStartsAtomI6x86_64EE
 N2ld4tool18UndefinedProxyAtomE
 N2ld4tool19ClassicLinkEditAtomE
 N2ld4tool19LazyBindingInfoAtomI3armEE
 N2ld4tool19LazyBindingInfoAtomI3x86EE
-N2ld4tool19LazyBindingInfoAtomI6x86_64EE
 N2ld4tool19SectionBoundaryAtomE
 N2ld4tool19SegmentBoundaryAtomE
 N2ld4tool19WeakBindingInfoAtomI3armEE
 N2ld4tool19WeakBindingInfoAtomI3x86EE
-N2ld4tool19WeakBindingInfoAtomI6x86_64EE
 N2ld4tool20LocalRelocationsAtomI3armEE
 N2ld4tool20LocalRelocationsAtomI3x86EE
-N2ld4tool20LocalRelocationsAtomI6x86_64EE
 N2ld4tool22SectionRelocationsAtomI3armEE
 N2ld4tool22SectionRelocationsAtomI3x86EE
-N2ld4tool22SectionRelocationsAtomI6x86_64EE
 N2ld4tool23ExternalRelocationsAtomI3armEE
 N2ld4tool23ExternalRelocationsAtomI3x86EE
-N2ld4tool23ExternalRelocationsAtomI6x86_64EE
 N2ld4tool23IndirectSymbolTableAtomI3armEE
 N2ld4tool23IndirectSymbolTableAtomI3x86EE
-N2ld4tool23IndirectSymbolTableAtomI6x86_64EE
 N2ld4tool23RelocationsAtomAbstractE
 N2ld4tool25HeaderAndLoadCommandsAtomI3armEE
 N2ld4tool25HeaderAndLoadCommandsAtomI3x86EE
-N2ld4tool25HeaderAndLoadCommandsAtomI6x86_64EE
 N2ld4tool28HeaderAndLoadCommandsAbtractE
 N2ld4tool8ResolverE
 N2ld4tool9AliasAtomE
@@ -657,18 +642,6 @@ N2ld6passes5stubs3x867classic14StubHelpe
 N2ld6passes5stubs3x867classic15LazyPointerAtomE
 N2ld6passes5stubs3x867classic8StubAtomE
 N2ld6passes5stubs3x868StubAtomE
-N2ld6passes5stubs6x86_6412KextStubAtomE
-N2ld6passes5stubs6x86_6414StubHelperAtomE
-N2ld6passes5stubs6x86_6415LazyPointerAtomE
-N2ld6passes5stubs6x86_6418NonLazyPointerAtomE
-N2ld6passes5stubs6x86_6418ResolverHelperAtomE
-N2ld6passes5stubs6x86_6420StubHelperHelperAtomE
-N2ld6passes5stubs6x86_6421ImageCachePointerAtomE
-N2ld6passes5stubs6x86_6422FastBindingPointerAtomE
-N2ld6passes5stubs6x86_647classic14StubHelperAtomE
-N2ld6passes5stubs6x86_647classic15LazyPointerAtomE
-N2ld6passes5stubs6x86_647classic8StubAtomE
-N2ld6passes5stubs6x86_648StubAtomE
 N2ld6passes6dtrace4AtomE
 N2ld6passes6dtrace4FileE
 N2ld7SectionE
@@ -679,74 +652,28 @@ N3lto4AtomE
 N3lto4FileE
 N3lto6Parser10AtomSyncerE
 N6mach_o11relocatable10CFISectionI3armEE
-N6mach_o11relocatable10CFISectionI3x86EE
-N6mach_o11relocatable10CFISectionI6x86_64EE
 N6mach_o11relocatable14CStringSectionI3armEE
-N6mach_o11relocatable14CStringSectionI3x86EE
-N6mach_o11relocatable14CStringSectionI6x86_64EE
 N6mach_o11relocatable14TLVDefsSectionI3armEE
-N6mach_o11relocatable14TLVDefsSectionI3x86EE
-N6mach_o11relocatable14TLVDefsSectionI6x86_64EE
 N6mach_o11relocatable15CFStringSectionI3armEE
-N6mach_o11relocatable15CFStringSectionI3x86EE
-N6mach_o11relocatable15CFStringSectionI6x86_64EE
 N6mach_o11relocatable15Literal4SectionI3armEE
-N6mach_o11relocatable15Literal4SectionI3x86EE
-N6mach_o11relocatable15Literal4SectionI6x86_64EE
 N6mach_o11relocatable15Literal8SectionI3armEE
-N6mach_o11relocatable15Literal8SectionI3x86EE
-N6mach_o11relocatable15Literal8SectionI6x86_64EE
 N6mach_o11relocatable15SymboledSectionI3armEE
-N6mach_o11relocatable15SymboledSectionI3x86EE
-N6mach_o11relocatable15SymboledSectionI6x86_64EE
 N6mach_o11relocatable16FixedSizeSectionI3armEE
-N6mach_o11relocatable16FixedSizeSectionI3x86EE
-N6mach_o11relocatable16FixedSizeSectionI6x86_64EE
 N6mach_o11relocatable16Literal16SectionI3armEE
-N6mach_o11relocatable16Literal16SectionI3x86EE
-N6mach_o11relocatable16Literal16SectionI6x86_64EE
 N6mach_o11relocatable17ObjC1ClassSectionI3armEE
-N6mach_o11relocatable17ObjC1ClassSectionI3x86EE
-N6mach_o11relocatable17ObjC1ClassSectionI6x86_64EE
 N6mach_o11relocatable18UTF16StringSectionI3armEE
-N6mach_o11relocatable18UTF16StringSectionI3x86EE
-N6mach_o11relocatable18UTF16StringSectionI6x86_64EE
 N6mach_o11relocatable19ImplicitSizeSectionI3armEE
-N6mach_o11relocatable19ImplicitSizeSectionI3x86EE
-N6mach_o11relocatable19ImplicitSizeSectionI6x86_64EE
 N6mach_o11relocatable20Objc1ClassReferencesI3armEE
-N6mach_o11relocatable20Objc1ClassReferencesI3x86EE
-N6mach_o11relocatable20Objc1ClassReferencesI6x86_64EE
 N6mach_o11relocatable21AbsoluteSymbolSectionI3armEE
-N6mach_o11relocatable21AbsoluteSymbolSectionI3x86EE
-N6mach_o11relocatable21AbsoluteSymbolSectionI6x86_64EE
 N6mach_o11relocatable21NonLazyPointerSectionI3armEE
-N6mach_o11relocatable21NonLazyPointerSectionI3x86EE
-N6mach_o11relocatable21NonLazyPointerSectionI6x86_64EE
 N6mach_o11relocatable21ObjC2ClassRefsSectionI3armEE
-N6mach_o11relocatable21ObjC2ClassRefsSectionI3x86EE
-N6mach_o11relocatable21ObjC2ClassRefsSectionI6x86_64EE
 N6mach_o11relocatable23PointerToCStringSectionI3armEE
-N6mach_o11relocatable23PointerToCStringSectionI3x86EE
-N6mach_o11relocatable23PointerToCStringSectionI6x86_64EE
 N6mach_o11relocatable24ObjC2CategoryListSectionI3armEE
-N6mach_o11relocatable24ObjC2CategoryListSectionI3x86EE
-N6mach_o11relocatable24ObjC2CategoryListSectionI6x86_64EE
 N6mach_o11relocatable26TentativeDefinitionSectionI3armEE
-N6mach_o11relocatable26TentativeDefinitionSectionI3x86EE
-N6mach_o11relocatable26TentativeDefinitionSectionI6x86_64EE
 N6mach_o11relocatable4AtomI3armEE
-N6mach_o11relocatable4AtomI3x86EE
-N6mach_o11relocatable4AtomI6x86_64EE
 N6mach_o11relocatable4FileI3armEE
-N6mach_o11relocatable4FileI3x86EE
-N6mach_o11relocatable4FileI6x86_64EE
 N6mach_o11relocatable7SectionI3armEE
-N6mach_o11relocatable7SectionI3x86EE
-N6mach_o11relocatable7SectionI6x86_64EE
 N6mach_o11relocatable9CUSectionI3armEE
-N6mach_o11relocatable9CUSectionI3x86EE
-N6mach_o11relocatable9CUSectionI6x86_64EE
 N6mach_o5dylib10ExportAtomI3armEE
 N6mach_o5dylib10ExportAtomI3x86EE
 N6mach_o5dylib10ExportAtomI6x86_64EE
@@ -1082,7 +1009,6 @@ categoryOnClassAtom != NULL
 cd %s
 cfa had negative offset (dwarf might contain epilog)
 cfiParse
-cfiStartsArray[i] != cfiStartsArray[i-1]
 cie->section().type() == ld::Section::typeCFI
 clang -arch $arch -c -fno-builtin -o tmp_object.o -x c dylib_stubs/$file
 clang -arch $arch -c -fno-builtin -o tmp_object.o -x c framework_stubs/$file

So obviously a bunch of symbols relating to x86_64 are gone...

That last one for cfiStartsArray[i] != cfiStartsArray[i-1] is interesting as it comes from:

        #ifndef NDEBUG
                // scan for FDEs claming the same function
                for(int i=1; i < index; ++i) {
                        assert( cfiStartsArray[i] != cfiStartsArray[i-1] );
                }
        #endif  

[jeremyhu (Jeremy Huddleston Sequoia)]

Looking at src/ld/OutputFile.cpp, it looks as if SUPPORT_ARCH_x86_64 wasn't defined for the bad build ... I think that would cause all those missing C++ class name strings.

But that doesn't make sense since SUPPORT_ARCH_x86_64 is supposed to be defined in configure.h which is created by create_configure during ld64's build, and it uses the value of RC_SUPPORTED_ARCHS, which should include x86_64 (and seems to based on the output of ld -v for the bad build ... puzzling)

I'll need to wait for my builds to finish to take a look at this more...

[jeremyhu (Jeremy Huddleston Sequoia)]

Following both of your examples produces working builds of ld64. You're going to have to try narrowing it down a bit more. I'll try on another machine =/

[jeremyhu (Jeremy Huddleston Sequoia)]

I wonder if some "differnet" configure.h is getting pulled in somehow ... that might explain why SUPPORT_ARCH_x86_64 isn't defined.

Please give r97801 a try...

[jeremyhu (Jeremy Huddleston Sequoia)]

Also, if you're still having issues, please use '-k' when you build to preserve your workdir and attach ld-configure.h

[jwhowse4]

Replying to jeremyhu@…:

I wonder if some "differnet" configure.h is getting pulled in somehow ... that might explain why SUPPORT_ARCH_x86_64 isn't defined.

Please give r97801 a try...

Also, if you're still having issues, please use '-k' when you build to preserve your workdir and attach ld-configure.h

All of my comments here apply to my regular MacPorts installation, not my experimental one. Your attempted fix in r97801 still leads to a linker that does not create an executable for my simple test code. For reference I saved a copy of the resulting linker. Unfortunately I did not run the upgrade with the -k option so I forced the uninstall of ld64 and reinstalled it with the -k option. This simple change in installation order produced a linker which is different than the copy I saved prior to uninstalling. I have copies of both linkers, if they would be useful to you let me know and I will attach them. I am attaching the ld-configure.h file that was generated by the reinstall. I fear it will not be helpful since #define SUPPORT_ARCH_x86_64 is set to 1 in it, while the resulting linker does not support that architecture.

[jwhowse4]

Configureation Header

[jeremyhu (Jeremy Huddleston Sequoia)]

No, that is helpful information to note. So your ld-configure.h is correct but the built ld is wrong... I was hoping that there was a configure.h somewhere which may have been pulled in instead. It was a stab in the dark =/

I haven't been able to reproduce this with those examples on my ML or Lion machine.

Would you be able to send me (dropbox or other means?) a tarball of your /opt/macports-test as they are in the step right before you install llvm-3.1 for each of your example cases?

Can you please attach the build log for ld64 in the working and broken case?

Can you attach preprocessed source for both the good and bad cases for macho_relocatable_file.cpp and src/ld/OutputFile.cpp? As an example for producing the preprocessed source, look at the build log and change the "-c -o src/ld/OutputFile.o" of the build line to "-E -o ~/Desktop/OutputFile.working.cpp"

[ryandesign (Ryan Carsten Schmidt)]

Replying to jeremyhu@…:

Please give r97801 a try...

After this rebuild, my ld is working correctly and I'm able to upgrade my *gcc* ports again.

[jeremyhu (Jeremy Huddleston Sequoia)]

This is so bizarre.

[ralph@…]

After r97801 and rebuilding ld64+llvm31 (etc) libstdcxx still fails to build for me

:info:build Comparing stages 2 and 3
:info:build warning: gcc/cc1-checksum.o differs
:info:build warning: gcc/cc1plus-checksum.o differs
:info:build Bootstrap comparison failure!
:info:build x86_64-apple-darwin12/libstdc++-v3/libsupc++/vec.o differs
:info:build make[2]: *** [compare] Error 1

but its not a linker error any more. I guess I should open another ticket on this...

[ralph@…]

Cc Me!

[ralph@…]

Solved the above problem by forcibly uninstalling the currently installed libstdcxx before trying to build the newer one.

[adrian@…]

Been rebuilding my system, and found that it coincided with the LD issue.

Finally got libstdcxx to install by doing these steps (some people have commented an easier build):

sudo port uninstall ld64
sudo port -v install ld64
sudo port clean libstdcxx
sudo port -d build libstdcxx build.jobs=1
sudo port install libstdcxx

[kitchen.andy@…]

Cc Me!

[roland@…]

Cc Me!

[neil.skilling@…]

Cc Me!

[kitchen.andy@…]

sudo port select gcc none

seemed to make libstdcxx compile for me, perhaps the currently selected gcc is leaking in to the build process?

It's hard to say though, because I was reinstalling a bunch of packages as well.

[jwhowse4]

Replying to jeremyhu@…:

No, that is helpful information to note. So your ld-configure.h is correct but the built ld is wrong... I was hoping that there was a configure.h somewhere which may have been pulled in instead. It was a stab in the dark =/

I haven't been able to reproduce this with those examples on my ML or Lion machine.

Would you be able to send me (dropbox or other means?) a tarball of your /opt/macports-test as they are in the step right before you install llvm-3.1 for each of your example cases?

Can you please attach the build log for ld64 in the working and broken case?

Can you attach preprocessed source for both the good and bad cases for macho_relocatable_file.cpp and src/ld/OutputFile.cpp? As an example for producing the preprocessed source, look at the build log and change the "-c -o src/ld/OutputFile.o" of the build line to "-E -o ~/Desktop/OutputFile.working.cpp"

Sorry about the delay, other things have demanded my attention. All of my current results are after upgrading to XCode 4.5.0 which just to spoil the surprise has not fixed my problem. After the XCode upgrade both my previous build examples produce linkers which fail on my simple test problem, but they still produce two different linkers. So I have attached two TAR files containing the ld64 build log and the macho_relocatable_file(.cpp.h.o) and OutputFile(.cpp.h.o) for both build examples. I am working on getting my DropBox account in order so I can share the complete macports distributions for both build examples just prior to the llvm install.

[jwhowse4]

Experiment #1 files

[jwhowse4]

Experiment #2 files

[jeremyhu (Jeremy Huddleston Sequoia)]

The most important thing that I need is the preprocessed source. Can you please prioritize that?

Thanks.

[alexoedelman@…]

Cc Me!

[elijah.epifanov@…]

Cc Me!

[elijah.epifanov@…]

Cc Me!

[elijah.epifanov@…]

Cc Me!

[jeremyhu (Jeremy Huddleston Sequoia)]

I have the macports-tst1 and macports-tst2 tarballs from your config. I'm going to extract them into /opt on my Lion machine with XCode 4.5 and do:

PATH=/opt/macports-tst1/bin:$PATH 
sudo port -v install llvm-3.1
sudo port -v install ld64 +llvm31

PATH=/opt/macports-tst2/bin:$PATH 
sudo port -v install llvm-3.1
sudo port -v install ld64 +llvm31

You're expecting that one of these will produce a working ld and one will not. By working / not working, we mean that using it to replace /opt/local/bin/ld will cause x86_64 code to link (or not link) when using one of MacPorts' gcc4X compilers.

Is that correct?

[jeremyhu (Jeremy Huddleston Sequoia)]

So I did what I said above, and both versions of ld have the N2ld4tool14DataInCodeAtomI6x86_64EE string (whereas your bad one didn't). Additionally, both seem to link an x86_64 executable just fine.

Ugg... so could you give me the full macports-tst1 and macports-tst2 (ie, build all the way through ld64 rather than stopping before llvm-3.1)? Additionally, please provide the preprocessed source for macho_relocatable_file.cpp and OutputFile.cpp for both the good and bad versions.

[jwhowse4]

Replying to jeremyhu@…:

I have the macports-tst1 and macports-tst2 tarballs from your config. I'm going to extract them into /opt on my Lion machine with XCode 4.5 and do:

PATH=/opt/macports-tst1/bin:$PATH 
sudo port -v install llvm-3.1
sudo port -v install ld64 +llvm31

PATH=/opt/macports-tst2/bin:$PATH 
sudo port -v install llvm-3.1
sudo port -v install ld64 +llvm31

You're expecting that one of these will produce a working ld and one will not. By working / not working, we mean that using it to replace /opt/local/bin/ld will cause x86_64 code to link (or not link) when using one of MacPorts' gcc4X compilers.

Is that correct?

Actually as I indicated in my initial reply, under XCode 4.5.0 neither of these examples gives me a working linker. In fact I have tried some other package orderings and so far I can not find an ordering which gives a working linker with XCode 4.5.0. Strangely every ordering gives me a different linker, but none of them work.

[jwhowse4]

Replying to jeremyhu@…:

So I did what I said above, and both versions of ld have the N2ld4tool14DataInCodeAtomI6x86_64EE string (whereas your bad one didn't). Additionally, both seem to link an x86_64 executable just fine.

Ugg... so could you give me the full macports-tst1 and macports-tst2 (ie, build all the way through ld64 rather than stopping before llvm-3.1)? Additionally, please provide the preprocessed source for macho_relocatable_file.cpp and OutputFile.cpp for both the good and bad versions.

I am unclear what you mean by preprocessed source for macho_relocatable_file.cpp and OutputFile.cpp. Also do you want these results even if both versions are bad?

[jeremyhu (Jeremy Huddleston Sequoia)]

Replying to jwhowse4@…:

Actually as I indicated in my initial reply, under XCode 4.5.0 neither of these examples gives me a working linker. In fact I have tried some other package orderings and so far I can not find an ordering which gives a working linker with XCode 4.5.0. Strangely every ordering gives me a different linker, but none of them work.

Exactly what Xcode version are you using to reproduce this with?

Replying to jwhowse4@…:

Replying to jeremyhu@…:

So I did what I said above, and both versions of ld have the N2ld4tool14DataInCodeAtomI6x86_64EE string (whereas your bad one didn't). Additionally, both seem to link an x86_64 executable just fine.

Ugg... so could you give me the full macports-tst1 and macports-tst2 (ie, build all the way through ld64 rather than stopping before llvm-3.1)? Additionally, please provide the preprocessed source for macho_relocatable_file.cpp and OutputFile.cpp for both the good and bad versions.

I am unclear what you mean by preprocessed source for macho_relocatable_file.cpp and OutputFile.cpp. Also do you want these results even if both versions are bad?

Yes, I want the good and bad versions.

The preprocessed source is the C code that is passed to the compiler after being preprocessed by the C preprocessor. The C preprocessor takes care of the #-directives, macro expansion, etc. You get those results using -E rather than -c.

Eg:

$ clang -c file.c -o file.o  # This will compile file.c and produce an object file
$ clang -E file.c -o file.preprocessed.c # This will save the preprocessed source

You will need to look through the build logs and produce the preprocessed source for the working and broken version.

[jwhowse4]

Replying to jeremyhu@…:

Replying to jwhowse4@…:

Actually as I indicated in my initial reply, under XCode 4.5.0 neither of these examples gives me a working linker. In fact I have tried some other package orderings and so far I can not find an ordering which gives a working linker with XCode 4.5.0. Strangely every ordering gives me a different linker, but none of them work.

Exactly what Xcode version are you using to reproduce this with?

Replying to jwhowse4@…:

Replying to jeremyhu@…:

So I did what I said above, and both versions of ld have the N2ld4tool14DataInCodeAtomI6x86_64EE string (whereas your bad one didn't). Additionally, both seem to link an x86_64 executable just fine.

Ugg... so could you give me the full macports-tst1 and macports-tst2 (ie, build all the way through ld64 rather than stopping before llvm-3.1)? Additionally, please provide the preprocessed source for macho_relocatable_file.cpp and OutputFile.cpp for both the good and bad versions.

I am unclear what you mean by preprocessed source for macho_relocatable_file.cpp and OutputFile.cpp. Also do you want these results even if both versions are bad?

Yes, I want the good and bad versions.

The preprocessed source is the C code that is passed to the compiler after being preprocessed by the C preprocessor. The C preprocessor takes care of the #-directives, macro expansion, etc. You get those results using -E rather than -c.

Eg:

$ clang -c file.c -o file.o  # This will compile file.c and produce an object file
$ clang -E file.c -o file.preprocessed.c # This will save the preprocessed source

You will need to look through the build logs and produce the preprocessed source for the working and broken version.

I am using the latest XCode for Lion from the AppStore which is listed as version 4.5. For this version of XCode there are no good versions, everything I try results in a bad version.

[jeremyhu (Jeremy Huddleston Sequoia)]

I understand that you are having no working path with 4.5. You said 4.4 gave you working in one order and not working in another, right? So please use 4.4 to provide me the information I need. I will need to see what is different at build time between your good and bad case.

[vaccari@…]

Having the problem with libstdcxx. Original failure trying to update gcc46. Tried all above suggestions, no success. Then removed /opt/local, reinstalled Macports from scratch, and issued

sudo port install libstdcxx

as the very first command. Here the session transcript, log file libstdcxx.log.zip just added.

sudo port install libstdcxx
--->  Computing dependencies for libstdcxx
--->  Dependencies to be installed: cctools cctools-headers ld64 dyld-headers libunwind-headers llvm-3.1 libffi llvm_select cloog gmp isl autoconf help2man gettext expat libiconv gperf ncurses p5.12-locale-gettext perl5.12 gdbm m4 perl5 xz automake libtool gcc_select libmpc mpfr ppl glpk zlib
--->  Fetching archive for cctools-headers
--->  Attempting to fetch cctools-headers-829_0.darwin_12.noarch.tbz2 from http://mse.uk.packages.macports.org/sites/packages.macports.org/cctools-headers
--->  Attempting to fetch cctools-headers-829_0.darwin_12.noarch.tbz2 from http://lil.fr.packages.macports.org/cctools-headers
--->  Attempting to fetch cctools-headers-829_0.darwin_12.noarch.tbz2 from http://packages.macports.org/cctools-headers
--->  Fetching distfiles for cctools-headers
--->  Attempting to fetch cctools-829.tar.gz from http://fco.it.distfiles.macports.org/mirrors/macports-distfiles/cctools-headers
--->  Attempting to fetch xnu-2050.9.2.tar.gz from http://fco.it.distfiles.macports.org/mirrors/macports-distfiles/cctools-headers
--->  Verifying checksum(s) for cctools-headers
--->  Extracting cctools-headers
--->  Configuring cctools-headers
--->  Building cctools-headers
--->  Staging cctools-headers into destroot
--->  Installing cctools-headers @829_0
--->  Activating cctools-headers @829_0
--->  Cleaning cctools-headers
--->  Fetching archive for dyld-headers
--->  Attempting to fetch dyld-headers-210.2.3_0.darwin_12.noarch.tbz2 from http://mse.uk.packages.macports.org/sites/packages.macports.org/dyld-headers
--->  Attempting to fetch dyld-headers-210.2.3_0.darwin_12.noarch.tbz2 from http://lil.fr.packages.macports.org/dyld-headers
--->  Attempting to fetch dyld-headers-210.2.3_0.darwin_12.noarch.tbz2 from http://packages.macports.org/dyld-headers
--->  Fetching distfiles for dyld-headers
--->  Attempting to fetch dyld-210.2.3.tar.gz from http://fco.it.distfiles.macports.org/mirrors/macports-distfiles/dyld-headers
--->  Verifying checksum(s) for dyld-headers
--->  Extracting dyld-headers
--->  Configuring dyld-headers
--->  Building dyld-headers
--->  Staging dyld-headers into destroot
--->  Installing dyld-headers @210.2.3_0
--->  Activating dyld-headers @210.2.3_0
--->  Cleaning dyld-headers
--->  Fetching archive for libunwind-headers
--->  Attempting to fetch libunwind-headers-35.1_0.darwin_12.noarch.tbz2 from http://mse.uk.packages.macports.org/sites/packages.macports.org/libunwind-headers
--->  Attempting to fetch libunwind-headers-35.1_0.darwin_12.noarch.tbz2 from http://lil.fr.packages.macports.org/libunwind-headers
--->  Attempting to fetch libunwind-headers-35.1_0.darwin_12.noarch.tbz2 from http://packages.macports.org/libunwind-headers
--->  Fetching distfiles for libunwind-headers
--->  Attempting to fetch libunwind-35.1.tar.gz from http://fco.it.distfiles.macports.org/mirrors/macports-distfiles/libunwind-headers
--->  Verifying checksum(s) for libunwind-headers
--->  Extracting libunwind-headers
--->  Configuring libunwind-headers
--->  Building libunwind-headers
--->  Staging libunwind-headers into destroot
--->  Installing libunwind-headers @35.1_0
--->  Activating libunwind-headers @35.1_0
--->  Cleaning libunwind-headers
--->  Fetching archive for libffi
--->  Attempting to fetch libffi-3.0.11_0.darwin_12.x86_64.tbz2 from http://mse.uk.packages.macports.org/sites/packages.macports.org/libffi
--->  Attempting to fetch libffi-3.0.11_0.darwin_12.x86_64.tbz2 from http://lil.fr.packages.macports.org/libffi
--->  Attempting to fetch libffi-3.0.11_0.darwin_12.x86_64.tbz2 from http://packages.macports.org/libffi
--->  Fetching distfiles for libffi
--->  Attempting to fetch libffi-3.0.11.tar.gz from http://fco.it.distfiles.macports.org/mirrors/macports-distfiles/libffi
--->  Verifying checksum(s) for libffi
--->  Extracting libffi
--->  Configuring libffi
--->  Building libffi
--->  Staging libffi into destroot
--->  Installing libffi @3.0.11_0
--->  Activating libffi @3.0.11_0
--->  Cleaning libffi
--->  Fetching archive for llvm_select
--->  Attempting to fetch llvm_select-0.2_0.darwin_12.noarch.tbz2 from http://mse.uk.packages.macports.org/sites/packages.macports.org/llvm_select
--->  Attempting to fetch llvm_select-0.2_0.darwin_12.noarch.tbz2 from http://lil.fr.packages.macports.org/llvm_select
--->  Attempting to fetch llvm_select-0.2_0.darwin_12.noarch.tbz2 from http://packages.macports.org/llvm_select
--->  Fetching distfiles for llvm_select
--->  Verifying checksum(s) for llvm_select
--->  Extracting llvm_select
--->  Configuring llvm_select
--->  Building llvm_select
--->  Staging llvm_select into destroot
--->  Installing llvm_select @0.2_0
--->  Activating llvm_select @0.2_0
--->  Cleaning llvm_select
--->  Fetching archive for llvm-3.1
--->  Attempting to fetch llvm-3.1-3.1_3.darwin_12.x86_64.tbz2 from http://mse.uk.packages.macports.org/sites/packages.macports.org/llvm-3.1
--->  Attempting to fetch llvm-3.1-3.1_3.darwin_12.x86_64.tbz2 from http://lil.fr.packages.macports.org/llvm-3.1
--->  Attempting to fetch llvm-3.1-3.1_3.darwin_12.x86_64.tbz2 from http://packages.macports.org/llvm-3.1
--->  Fetching distfiles for llvm-3.1
--->  Attempting to fetch llvm-3.1.src.tar.gz from http://fco.it.distfiles.macports.org/mirrors/macports-distfiles/llvm
--->  Verifying checksum(s) for llvm-3.1
--->  Extracting llvm-3.1
--->  Applying patches to llvm-3.1
--->  Configuring llvm-3.1
--->  Building llvm-3.1
--->  Staging llvm-3.1 into destroot
--->  Installing llvm-3.1 @3.1_3
--->  Activating llvm-3.1 @3.1_3
--->  Cleaning llvm-3.1
--->  Fetching archive for ld64
--->  Attempting to fetch ld64-133.3_3+llvm31.darwin_12.x86_64.tbz2 from http://mse.uk.packages.macports.org/sites/packages.macports.org/ld64
--->  Attempting to fetch ld64-133.3_3+llvm31.darwin_12.x86_64.tbz2 from http://lil.fr.packages.macports.org/ld64
--->  Attempting to fetch ld64-133.3_3+llvm31.darwin_12.x86_64.tbz2 from http://packages.macports.org/ld64
--->  Fetching distfiles for ld64
--->  Attempting to fetch ld64-133.3.tar.gz from http://fco.it.distfiles.macports.org/mirrors/macports-distfiles/ld64
--->  Verifying checksum(s) for ld64
--->  Extracting ld64
--->  Applying patches to ld64
--->  Configuring ld64
--->  Building ld64
--->  Staging ld64 into destroot
--->  Installing ld64 @133.3_3+llvm31
--->  Activating ld64 @133.3_3+llvm31
--->  Cleaning ld64
--->  Fetching archive for cctools
--->  Attempting to fetch cctools-829_1+llvm31.darwin_12.x86_64.tbz2 from http://mse.uk.packages.macports.org/sites/packages.macports.org/cctools
--->  Attempting to fetch cctools-829_1+llvm31.darwin_12.x86_64.tbz2 from http://lil.fr.packages.macports.org/cctools
--->  Attempting to fetch cctools-829_1+llvm31.darwin_12.x86_64.tbz2 from http://packages.macports.org/cctools
--->  Fetching distfiles for cctools
--->  Attempting to fetch cctools-829.tar.gz from http://fco.it.distfiles.macports.org/mirrors/macports-distfiles/cctools
--->  Verifying checksum(s) for cctools
--->  Extracting cctools
--->  Applying patches to cctools
--->  Configuring cctools
--->  Building cctools
--->  Staging cctools into destroot
--->  Installing cctools @829_1+llvm31
--->  Activating cctools @829_1+llvm31
--->  Cleaning cctools
--->  Fetching archive for gmp
--->  Attempting to fetch gmp-5.0.4_1.darwin_12.x86_64.tbz2 from http://mse.uk.packages.macports.org/sites/packages.macports.org/gmp
--->  Attempting to fetch gmp-5.0.4_1.darwin_12.x86_64.tbz2 from http://lil.fr.packages.macports.org/gmp
--->  Attempting to fetch gmp-5.0.4_1.darwin_12.x86_64.tbz2 from http://packages.macports.org/gmp
--->  Fetching distfiles for gmp
--->  Attempting to fetch gmp-5.0.4.tar.bz2 from http://fco.it.distfiles.macports.org/mirrors/macports-distfiles/gmp
--->  Verifying checksum(s) for gmp
--->  Extracting gmp
--->  Applying patches to gmp
--->  Configuring gmp
--->  Building gmp
--->  Staging gmp into destroot
--->  Installing gmp @5.0.4_1
--->  Activating gmp @5.0.4_1
--->  Cleaning gmp
--->  Fetching archive for expat
--->  Attempting to fetch expat-2.1.0_0.darwin_12.x86_64.tbz2 from http://mse.uk.packages.macports.org/sites/packages.macports.org/expat
--->  Attempting to fetch expat-2.1.0_0.darwin_12.x86_64.tbz2 from http://lil.fr.packages.macports.org/expat
--->  Attempting to fetch expat-2.1.0_0.darwin_12.x86_64.tbz2 from http://packages.macports.org/expat
--->  Fetching distfiles for expat
--->  Attempting to fetch expat-2.1.0.tar.gz from http://fco.it.distfiles.macports.org/mirrors/macports-distfiles/expat
--->  Verifying checksum(s) for expat
--->  Extracting expat
--->  Configuring expat
--->  Building expat
--->  Staging expat into destroot
--->  Installing expat @2.1.0_0
--->  Activating expat @2.1.0_0
--->  Cleaning expat
--->  Fetching archive for gperf
--->  Attempting to fetch gperf-3.0.4_2.darwin_12.x86_64.tbz2 from http://mse.uk.packages.macports.org/sites/packages.macports.org/gperf
--->  Attempting to fetch gperf-3.0.4_2.darwin_12.x86_64.tbz2 from http://lil.fr.packages.macports.org/gperf
--->  Attempting to fetch gperf-3.0.4_2.darwin_12.x86_64.tbz2 from http://packages.macports.org/gperf
--->  Fetching distfiles for gperf
--->  Attempting to fetch gperf-3.0.4.tar.gz from http://fco.it.distfiles.macports.org/mirrors/macports-distfiles/gperf
--->  Verifying checksum(s) for gperf
--->  Extracting gperf
--->  Applying patches to gperf
--->  Configuring gperf
--->  Building gperf
--->  Staging gperf into destroot
--->  Installing gperf @3.0.4_2
--->  Activating gperf @3.0.4_2
--->  Cleaning gperf
--->  Fetching archive for libiconv
--->  Attempting to fetch libiconv-1.14_0.darwin_12.x86_64.tbz2 from http://mse.uk.packages.macports.org/sites/packages.macports.org/libiconv
--->  Attempting to fetch libiconv-1.14_0.darwin_12.x86_64.tbz2 from http://lil.fr.packages.macports.org/libiconv
--->  Attempting to fetch libiconv-1.14_0.darwin_12.x86_64.tbz2 from http://packages.macports.org/libiconv
--->  Fetching distfiles for libiconv
--->  Attempting to fetch libiconv-1.14.tar.gz from http://fco.it.distfiles.macports.org/mirrors/macports-distfiles/libiconv
--->  Verifying checksum(s) for libiconv
--->  Extracting libiconv
--->  Applying patches to libiconv
--->  Configuring libiconv
--->  Building libiconv
--->  Staging libiconv into destroot
--->  Installing libiconv @1.14_0
--->  Activating libiconv @1.14_0
--->  Cleaning libiconv
--->  Fetching archive for ncurses
--->  Attempting to fetch ncurses-5.9_1.darwin_12.x86_64.tbz2 from http://mse.uk.packages.macports.org/sites/packages.macports.org/ncurses
--->  Attempting to fetch ncurses-5.9_1.darwin_12.x86_64.tbz2 from http://lil.fr.packages.macports.org/ncurses
--->  Attempting to fetch ncurses-5.9_1.darwin_12.x86_64.tbz2 from http://packages.macports.org/ncurses
--->  Fetching distfiles for ncurses
--->  Attempting to fetch ncurses-5.9.tar.gz from http://fco.it.distfiles.macports.org/mirrors/macports-distfiles/ncurses
--->  Verifying checksum(s) for ncurses
--->  Extracting ncurses
--->  Applying patches to ncurses
--->  Configuring ncurses
--->  Building ncurses
--->  Staging ncurses into destroot
--->  Installing ncurses @5.9_1
--->  Activating ncurses @5.9_1
--->  Cleaning ncurses
--->  Fetching archive for gettext
--->  Attempting to fetch gettext-0.18.1.1_2.darwin_12.x86_64.tbz2 from http://mse.uk.packages.macports.org/sites/packages.macports.org/gettext
--->  Attempting to fetch gettext-0.18.1.1_2.darwin_12.x86_64.tbz2 from http://lil.fr.packages.macports.org/gettext
--->  Attempting to fetch gettext-0.18.1.1_2.darwin_12.x86_64.tbz2 from http://packages.macports.org/gettext
--->  Fetching distfiles for gettext
--->  Attempting to fetch gettext-0.18.1.1.tar.gz from http://fco.it.distfiles.macports.org/mirrors/macports-distfiles/gettext
--->  Verifying checksum(s) for gettext
--->  Extracting gettext
--->  Applying patches to gettext
--->  Configuring gettext
--->  Building gettext
--->  Staging gettext into destroot
--->  Installing gettext @0.18.1.1_2
--->  Activating gettext @0.18.1.1_2
--->  Cleaning gettext
--->  Fetching archive for gdbm
--->  Attempting to fetch gdbm-1.10_2.darwin_12.x86_64.tbz2 from http://mse.uk.packages.macports.org/sites/packages.macports.org/gdbm
--->  Attempting to fetch gdbm-1.10_2.darwin_12.x86_64.tbz2 from http://lil.fr.packages.macports.org/gdbm
--->  Attempting to fetch gdbm-1.10_2.darwin_12.x86_64.tbz2 from http://packages.macports.org/gdbm
--->  Fetching distfiles for gdbm
--->  Attempting to fetch gdbm-1.10.tar.gz from http://fco.it.distfiles.macports.org/mirrors/macports-distfiles/gdbm
--->  Verifying checksum(s) for gdbm
--->  Extracting gdbm
--->  Configuring gdbm
--->  Building gdbm
--->  Staging gdbm into destroot
--->  Installing gdbm @1.10_2
--->  Activating gdbm @1.10_2
--->  Cleaning gdbm
--->  Fetching archive for perl5.12
--->  Attempting to fetch perl5.12-5.12.4_1.darwin_12.x86_64.tbz2 from http://mse.uk.packages.macports.org/sites/packages.macports.org/perl5.12
--->  Attempting to fetch perl5.12-5.12.4_1.darwin_12.x86_64.tbz2 from http://lil.fr.packages.macports.org/perl5.12
--->  Attempting to fetch perl5.12-5.12.4_1.darwin_12.x86_64.tbz2 from http://packages.macports.org/perl5.12
--->  Fetching distfiles for perl5.12
--->  Attempting to fetch perl-5.12.4.tar.bz2 from http://fco.it.distfiles.macports.org/mirrors/macports-distfiles/perl5.12
--->  Verifying checksum(s) for perl5.12
--->  Extracting perl5.12
--->  Applying patches to perl5.12
--->  Configuring perl5.12
--->  Building perl5.12
--->  Staging perl5.12 into destroot
--->  Installing perl5.12 @5.12.4_1
--->  Activating perl5.12 @5.12.4_1
--->  Cleaning perl5.12
--->  Fetching archive for p5.12-locale-gettext
--->  Attempting to fetch p5.12-locale-gettext-1.50.0_7.darwin_12.x86_64.tbz2 from http://mse.uk.packages.macports.org/sites/packages.macports.org/p5.12-locale-gettext
--->  Attempting to fetch p5.12-locale-gettext-1.50.0_7.darwin_12.x86_64.tbz2 from http://lil.fr.packages.macports.org/p5.12-locale-gettext
--->  Attempting to fetch p5.12-locale-gettext-1.50.0_7.darwin_12.x86_64.tbz2 from http://packages.macports.org/p5.12-locale-gettext
--->  Fetching distfiles for p5.12-locale-gettext
--->  Attempting to fetch gettext-1.05.tar.gz from http://fco.it.distfiles.macports.org/mirrors/macports-distfiles/perl5
--->  Verifying checksum(s) for p5.12-locale-gettext
--->  Extracting p5.12-locale-gettext
--->  Applying patches to p5.12-locale-gettext
--->  Configuring p5.12-locale-gettext
--->  Building p5.12-locale-gettext
--->  Staging p5.12-locale-gettext into destroot
--->  Installing p5.12-locale-gettext @1.50.0_7
--->  Activating p5.12-locale-gettext @1.50.0_7
--->  Cleaning p5.12-locale-gettext
--->  Fetching archive for help2man
--->  Attempting to fetch help2man-1.40.10_0.darwin_12.x86_64.tbz2 from http://mse.uk.packages.macports.org/sites/packages.macports.org/help2man
--->  Attempting to fetch help2man-1.40.10_0.darwin_12.x86_64.tbz2 from http://lil.fr.packages.macports.org/help2man
--->  Attempting to fetch help2man-1.40.10_0.darwin_12.x86_64.tbz2 from http://packages.macports.org/help2man
--->  Fetching distfiles for help2man
--->  Attempting to fetch help2man-1.40.10.tar.gz from http://fco.it.distfiles.macports.org/mirrors/macports-distfiles/help2man
--->  Verifying checksum(s) for help2man
--->  Extracting help2man
--->  Configuring help2man
--->  Building help2man
--->  Staging help2man into destroot
--->  Installing help2man @1.40.10_0
--->  Activating help2man @1.40.10_0
--->  Cleaning help2man
--->  Fetching archive for m4
--->  Attempting to fetch m4-1.4.16_0.darwin_12.x86_64.tbz2 from http://mse.uk.packages.macports.org/sites/packages.macports.org/m4
--->  Attempting to fetch m4-1.4.16_0.darwin_12.x86_64.tbz2 from http://lil.fr.packages.macports.org/m4
--->  Attempting to fetch m4-1.4.16_0.darwin_12.x86_64.tbz2 from http://packages.macports.org/m4
--->  Fetching distfiles for m4
--->  Attempting to fetch m4-1.4.16.tar.bz2 from http://fco.it.distfiles.macports.org/mirrors/macports-distfiles/m4
--->  Verifying checksum(s) for m4
--->  Extracting m4
--->  Configuring m4
--->  Building m4
--->  Staging m4 into destroot
--->  Installing m4 @1.4.16_0
--->  Activating m4 @1.4.16_0
--->  Cleaning m4
--->  Fetching archive for perl5
--->  Attempting to fetch perl5-5.12.4_0+perl5_12.darwin_12.noarch.tbz2 from http://mse.uk.packages.macports.org/sites/packages.macports.org/perl5
--->  Attempting to fetch perl5-5.12.4_0+perl5_12.darwin_12.noarch.tbz2 from http://lil.fr.packages.macports.org/perl5
--->  Attempting to fetch perl5-5.12.4_0+perl5_12.darwin_12.noarch.tbz2 from http://packages.macports.org/perl5
--->  Fetching distfiles for perl5
--->  Verifying checksum(s) for perl5
--->  Extracting perl5
--->  Configuring perl5
--->  Building perl5
--->  Staging perl5 into destroot
--->  Installing perl5 @5.12.4_0+perl5_12
--->  Activating perl5 @5.12.4_0+perl5_12
--->  Cleaning perl5
--->  Fetching archive for xz
--->  Attempting to fetch xz-5.0.4_0.darwin_12.x86_64.tbz2 from http://mse.uk.packages.macports.org/sites/packages.macports.org/xz
--->  Attempting to fetch xz-5.0.4_0.darwin_12.x86_64.tbz2 from http://lil.fr.packages.macports.org/xz
--->  Attempting to fetch xz-5.0.4_0.darwin_12.x86_64.tbz2 from http://packages.macports.org/xz
--->  Fetching distfiles for xz
--->  Attempting to fetch xz-5.0.4.tar.bz2 from http://fco.it.distfiles.macports.org/mirrors/macports-distfiles/xz
--->  Verifying checksum(s) for xz
--->  Extracting xz
--->  Configuring xz
--->  Building xz
--->  Staging xz into destroot
--->  Installing xz @5.0.4_0
--->  Activating xz @5.0.4_0
--->  Cleaning xz
--->  Fetching archive for autoconf
--->  Attempting to fetch autoconf-2.69_0.darwin_12.noarch.tbz2 from http://mse.uk.packages.macports.org/sites/packages.macports.org/autoconf
--->  Attempting to fetch autoconf-2.69_0.darwin_12.noarch.tbz2 from http://lil.fr.packages.macports.org/autoconf
--->  Attempting to fetch autoconf-2.69_0.darwin_12.noarch.tbz2 from http://packages.macports.org/autoconf
--->  Fetching distfiles for autoconf
--->  Attempting to fetch autoconf-2.69.tar.xz from http://fco.it.distfiles.macports.org/mirrors/macports-distfiles/autoconf
--->  Verifying checksum(s) for autoconf
--->  Extracting autoconf
--->  Configuring autoconf
--->  Building autoconf
--->  Staging autoconf into destroot
--->  Installing autoconf @2.69_0
--->  Activating autoconf @2.69_0
--->  Cleaning autoconf
--->  Fetching archive for automake
--->  Attempting to fetch automake-1.12.4_0.darwin_12.noarch.tbz2 from http://mse.uk.packages.macports.org/sites/packages.macports.org/automake
--->  Attempting to fetch automake-1.12.4_0.darwin_12.noarch.tbz2 from http://lil.fr.packages.macports.org/automake
--->  Attempting to fetch automake-1.12.4_0.darwin_12.noarch.tbz2 from http://packages.macports.org/automake
--->  Fetching distfiles for automake
--->  Attempting to fetch automake-1.12.4.tar.gz from http://fco.it.distfiles.macports.org/mirrors/macports-distfiles/automake
--->  Verifying checksum(s) for automake
--->  Extracting automake
--->  Configuring automake
--->  Building automake
--->  Staging automake into destroot
--->  Installing automake @1.12.4_0
--->  Activating automake @1.12.4_0
--->  Cleaning automake
--->  Fetching archive for libtool
--->  Attempting to fetch libtool-2.4.2_3.darwin_12.x86_64.tbz2 from http://mse.uk.packages.macports.org/sites/packages.macports.org/libtool
--->  Attempting to fetch libtool-2.4.2_3.darwin_12.x86_64.tbz2 from http://lil.fr.packages.macports.org/libtool
--->  Attempting to fetch libtool-2.4.2_3.darwin_12.x86_64.tbz2 from http://packages.macports.org/libtool
--->  Fetching distfiles for libtool
--->  Attempting to fetch libtool-2.4.2.tar.gz from http://fco.it.distfiles.macports.org/mirrors/macports-distfiles/libtool
--->  Verifying checksum(s) for libtool
--->  Extracting libtool
--->  Applying patches to libtool
--->  Configuring libtool
--->  Building libtool
--->  Staging libtool into destroot
--->  Installing libtool @2.4.2_3
--->  Activating libtool @2.4.2_3
--->  Cleaning libtool
--->  Fetching archive for isl
--->  Attempting to fetch isl-0.07_2.darwin_12.x86_64.tbz2 from http://mse.uk.packages.macports.org/sites/packages.macports.org/isl
--->  Attempting to fetch isl-0.07_2.darwin_12.x86_64.tbz2 from http://lil.fr.packages.macports.org/isl
--->  Attempting to fetch isl-0.07_2.darwin_12.x86_64.tbz2 from http://packages.macports.org/isl
--->  Fetching distfiles for isl
--->  Attempting to fetch isl-0.07.tar.bz2 from http://fco.it.distfiles.macports.org/mirrors/macports-distfiles/isl
--->  Verifying checksum(s) for isl
--->  Extracting isl
--->  Applying patches to isl
--->  Configuring isl
--->  Building isl
--->  Staging isl into destroot
--->  Installing isl @0.07_2
--->  Activating isl @0.07_2
--->  Cleaning isl
--->  Fetching archive for cloog
--->  Attempting to fetch cloog-0.16.3_2.darwin_12.x86_64.tbz2 from http://mse.uk.packages.macports.org/sites/packages.macports.org/cloog
--->  Attempting to fetch cloog-0.16.3_2.darwin_12.x86_64.tbz2 from http://lil.fr.packages.macports.org/cloog
--->  Attempting to fetch cloog-0.16.3_2.darwin_12.x86_64.tbz2 from http://packages.macports.org/cloog
--->  Fetching distfiles for cloog
--->  Attempting to fetch cloog-0.16.3.tar.gz from http://fco.it.distfiles.macports.org/mirrors/macports-distfiles/cloog
--->  Verifying checksum(s) for cloog
--->  Extracting cloog
--->  Applying patches to cloog
--->  Configuring cloog
--->  Building cloog
--->  Staging cloog into destroot
--->  Installing cloog @0.16.3_2
--->  Activating cloog @0.16.3_2
--->  Cleaning cloog
--->  Fetching archive for gcc_select
--->  Attempting to fetch gcc_select-0.1_7.darwin_12.noarch.tbz2 from http://mse.uk.packages.macports.org/sites/packages.macports.org/gcc_select
--->  Attempting to fetch gcc_select-0.1_7.darwin_12.noarch.tbz2 from http://lil.fr.packages.macports.org/gcc_select
--->  Attempting to fetch gcc_select-0.1_7.darwin_12.noarch.tbz2 from http://packages.macports.org/gcc_select
--->  Fetching distfiles for gcc_select
--->  Verifying checksum(s) for gcc_select
--->  Extracting gcc_select
--->  Configuring gcc_select
--->  Building gcc_select
--->  Staging gcc_select into destroot
--->  Installing gcc_select @0.1_7
--->  Activating gcc_select @0.1_7
--->  Cleaning gcc_select
--->  Fetching archive for mpfr
--->  Attempting to fetch mpfr-3.1.0-p3_1.darwin_12.x86_64.tbz2 from http://mse.uk.packages.macports.org/sites/packages.macports.org/mpfr
--->  Attempting to fetch mpfr-3.1.0-p3_1.darwin_12.x86_64.tbz2 from http://lil.fr.packages.macports.org/mpfr
--->  Attempting to fetch mpfr-3.1.0-p3_1.darwin_12.x86_64.tbz2 from http://packages.macports.org/mpfr
--->  Fetching distfiles for mpfr
--->  Attempting to fetch patch01 from http://fco.it.distfiles.macports.org/mirrors/macports-distfiles/mpfr/3.1.0
--->  Attempting to fetch patch02 from http://fco.it.distfiles.macports.org/mirrors/macports-distfiles/mpfr/3.1.0
--->  Attempting to fetch patch03 from http://fco.it.distfiles.macports.org/mirrors/macports-distfiles/mpfr/3.1.0
--->  Attempting to fetch mpfr-3.1.0.tar.xz from http://fco.it.distfiles.macports.org/mirrors/macports-distfiles/mpfr/3.1.0
--->  Verifying checksum(s) for mpfr
--->  Extracting mpfr
--->  Applying patches to mpfr
--->  Configuring mpfr
--->  Building mpfr
--->  Staging mpfr into destroot
--->  Installing mpfr @3.1.0-p3_1
--->  Activating mpfr @3.1.0-p3_1
--->  Cleaning mpfr
--->  Fetching archive for libmpc
--->  Attempting to fetch libmpc-1.0.1_0.darwin_12.x86_64.tbz2 from http://mse.uk.packages.macports.org/sites/packages.macports.org/libmpc
--->  Attempting to fetch libmpc-1.0.1_0.darwin_12.x86_64.tbz2 from http://lil.fr.packages.macports.org/libmpc
--->  Attempting to fetch libmpc-1.0.1_0.darwin_12.x86_64.tbz2 from http://packages.macports.org/libmpc
--->  Fetching distfiles for libmpc
--->  Attempting to fetch mpc-1.0.1.tar.gz from http://fco.it.distfiles.macports.org/mirrors/macports-distfiles/libmpc
--->  Verifying checksum(s) for libmpc
--->  Extracting libmpc
--->  Configuring libmpc
--->  Building libmpc
--->  Staging libmpc into destroot
--->  Installing libmpc @1.0.1_0
--->  Activating libmpc @1.0.1_0
--->  Cleaning libmpc
--->  Fetching archive for zlib
--->  Attempting to fetch zlib-1.2.7_0.darwin_12.x86_64.tbz2 from http://mse.uk.packages.macports.org/sites/packages.macports.org/zlib
--->  Attempting to fetch zlib-1.2.7_0.darwin_12.x86_64.tbz2 from http://lil.fr.packages.macports.org/zlib
--->  Attempting to fetch zlib-1.2.7_0.darwin_12.x86_64.tbz2 from http://packages.macports.org/zlib
--->  Fetching distfiles for zlib
--->  Attempting to fetch zlib-1.2.7.tar.bz2 from http://fco.it.distfiles.macports.org/mirrors/macports-distfiles/zlib
--->  Verifying checksum(s) for zlib
--->  Extracting zlib
--->  Configuring zlib
--->  Building zlib
--->  Staging zlib into destroot
--->  Installing zlib @1.2.7_0
--->  Activating zlib @1.2.7_0
--->  Cleaning zlib
--->  Fetching archive for glpk
--->  Attempting to fetch glpk-4.47_0.darwin_12.x86_64.tbz2 from http://mse.uk.packages.macports.org/sites/packages.macports.org/glpk
--->  Attempting to fetch glpk-4.47_0.darwin_12.x86_64.tbz2 from http://lil.fr.packages.macports.org/glpk
--->  Attempting to fetch glpk-4.47_0.darwin_12.x86_64.tbz2 from http://packages.macports.org/glpk
--->  Fetching distfiles for glpk
--->  Attempting to fetch glpk-4.47.tar.gz from http://fco.it.distfiles.macports.org/mirrors/macports-distfiles/glpk
--->  Verifying checksum(s) for glpk
--->  Extracting glpk
--->  Configuring glpk
--->  Building glpk
--->  Staging glpk into destroot
--->  Installing glpk @4.47_0
--->  Activating glpk @4.47_0
--->  Cleaning glpk
--->  Fetching archive for ppl
--->  Attempting to fetch ppl-1.0_0.darwin_12.x86_64.tbz2 from http://mse.uk.packages.macports.org/sites/packages.macports.org/ppl
--->  Attempting to fetch ppl-1.0_0.darwin_12.x86_64.tbz2 from http://lil.fr.packages.macports.org/ppl
--->  Attempting to fetch ppl-1.0_0.darwin_12.x86_64.tbz2 from http://packages.macports.org/ppl
--->  Fetching distfiles for ppl
--->  Attempting to fetch ppl-1.0.tar.bz2 from http://fco.it.distfiles.macports.org/mirrors/macports-distfiles/ppl
--->  Verifying checksum(s) for ppl
--->  Extracting ppl
--->  Configuring ppl
--->  Building ppl
--->  Staging ppl into destroot
--->  Installing ppl @1.0_0
--->  Activating ppl @1.0_0
--->  Cleaning ppl
--->  Fetching archive for libstdcxx
--->  Attempting to fetch libstdcxx-4.7.1_101.darwin_12.x86_64.tbz2 from http://mse.uk.packages.macports.org/sites/packages.macports.org/libstdcxx
--->  Attempting to fetch libstdcxx-4.7.1_101.darwin_12.x86_64.tbz2 from http://lil.fr.packages.macports.org/libstdcxx
--->  Attempting to fetch libstdcxx-4.7.1_101.darwin_12.x86_64.tbz2 from http://packages.macports.org/libstdcxx
--->  Fetching distfiles for libstdcxx
--->  Attempting to fetch gcc-4.7.1.tar.bz2 from http://fco.it.distfiles.macports.org/mirrors/macports-distfiles/gcc47
--->  Attempting to fetch ecj-4.5.jar from http://fco.it.distfiles.macports.org/mirrors/macports-distfiles/gcc47
--->  Verifying checksum(s) for libstdcxx
--->  Extracting libstdcxx
--->  Applying patches to libstdcxx
--->  Configuring libstdcxx
--->  Building libstdcxx
Error: org.macports.build for port libstdcxx returned: command execution failed
Please see the log file for port libstdcxx for details:
    /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_gcc47/libstdcxx/main.log
To report a bug, follow the instructions in the guide:
    http://guide.macports.org/#project.tickets
Error: Processing of port libstdcxx failed

MacBook Pro Retina, Os X 10.8.2, Xcode 4.5, MacPorts 2.1.2

[vaccari@…]

full config log taken from /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_gcc47/libstdcxx/work/build/build-x86_64-apple-darwin12/fixincludes/config.log

[vaccari@…]

I don't' know much of what I'm looking at, but in file

/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_gcc47/libstdcxx/work/build/build-x86_64-apple-darwin12/fixincludes/config.log

I see lots of errors like this:

...
...
Target: x86_64-apple-darwin12.2.0
Thread model: posix
configure:3590: $? = 0
configure:3579: /usr/bin/clang -arch x86_64 -v >&5
Apple clang version 4.1 (tags/Apple/clang-421.11.65) (based on LLVM 3.1svn)
Target: x86_64-apple-darwin12.2.0
Thread model: posix
configure:3590: $? = 0
configure:3579: /usr/bin/clang -arch x86_64 -V >&5
clang: error: argument to '-V' is missing (expected 1 value)
clang: error: no input files
...
...

Should -V really be -v there?

Full config log attached

HTH

[ajsilverton (Aron Silverton)]

Replying to jwhowse4@…:

Replying to jeremyhu@…:

I then tried replacing the linker ld from the ld64 port with the apple linker from Xcode 4.4.1

Can you please tell me *precisely* what you did here since there is actually a lot more room for ambiguity in that statement than you realize.

What is the output of?

/path/to/ld -v

Where /path/to/ld is the "updated" ld that you replaced.

In the directory /opt/macports/bin (which is where I put MacPorts) I ran the following commands.

mv ld ld.macports
ln -s /usr/bin/ld ld

Now the command /opt/macports/bin/ld -v gives

@(#)PROGRAM:ld  PROJECT:ld64-133.3
configured to support archs: armv6 armv7 i386 x86_64
LTO support using: LLVM version 3.1svn, from Apple Clang 4.0 (build 421.0.60)

I can confirm that:

mv ld ld.bak
ln -s /usr/bin/ld ld

Is a workaround. I can now build Macports that depend on GCC, libstdcxx, etc.

I'm looking forward to a permanent fix.

[ajsilverton (Aron Silverton)]

Cc Me!

[ryandesign (Ryan Carsten Schmidt)]

Replying to vaccari@…:

I don't' know much of what I'm looking at, but in file

/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_gcc47/libstdcxx/work/build/build-x86_64-apple-darwin12/fixincludes/config.log

I see lots of errors like this:

That's probably normal. The purpose of a configure script is to try various commands with various options to see which options happen to be supported on your system.

[vaccari@…]

I confirm here that after creating the symbolic link

ln -s /usr/bin/ld ld

libstdcxx compiles and installs. Now started rebuilding all other packages I need. Will I need to rebuild everything once a working MacPorts ld will be available?

Thanks for the workaround!

Franco

[jeremyhu (Jeremy Huddleston Sequoia)]

Replying to aron.j.silverton@…:

I can confirm that:

mv ld ld.bak
ln -s /usr/bin/ld ld

Is a workaround. I can now build Macports that depend on GCC, libstdcxx, etc.

I'm looking forward to a permanent fix.

The only way a fix will be found is if those of you with the problem can figure out what the problem is or help me to reproduce it. This does not occur for me on any system, and it looks like the issue isn't occuring for any other MacPorts developers. I'd like to see the preprocessed source code for macho_relocatable_file.cpp and OutputFile.cpp and the corresponding "broken" ld.

[vaccari@…]

Ok, tomorrow I'll rename the currently working installation on my laptop and reinstall MacPorts from scratch. Then I'll build libstdcxx so that I expect the error to show up again. At that point I'll be hopefully able to provide some useful info. Please specify the full path of the files that you want me to add as attachments.

[jeremyhu (Jeremy Huddleston Sequoia)]

They don't exist. You need to create them by looking at your ld64 build log and following the instructions I laid out above.

[vaccari@…]

Ok, so I'v reinstalled MacPorts and have again a broken system. Broken in the sense that I can't install libstdcxx. Looking at the log, the first reference to a wrong architecture regards _muldi3_s.o

So I searched for *muldi3* in the tree, then

cd /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_gcc47/libstdcxx/work/gcc-4.7.1/libgcc

and

sudo clang -E -B/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_gcc47/libstdcxx/work/build/./gcc/ -B/opt/local/x86_64-apple-darwin12/bin/ -B/opt/local/x86_64-apple-darwin12/lib/ -isystem /opt/local/x86_64-apple-darwin12/include -isystem /opt/local/x86_64-apple-darwin12/sys-include -g -pipe -O2 -O2 -g -pipe -O2 -DIN_GCC -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -pipe -fno-common -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -pipe -fno-common -I. -I../gcc -I../include -I../../build/gcc -DHAVE_CC_TLS -DUSE_EMUTLS -o _muldi3_s.o -MT _muldi3_s.o -MD -MP -MF _muldi3_s.dep -DSHARED -DL_muldi3 -c libgcc2.c -I../../build/x86_64-apple-darwin12/libgcc

Note that from the log I understand that gccx was used instead of clang, if that's relevant. Also, I adjusted the -I options to properly find the required headers, since I was issuing the clang command right from the directory.

The command succeeded, the only warning being:

clang: warning: argument unused during compilation: '-fbuilding-libgcc'

I'm attaching the _muldi3_s.o file for your checking

[vaccari@…]

Hmmm, I repeated the above after reactivating the working MacPorts installation, and _muldi3_s.o shows no difference, so I'm assuming I'm not doing anything useful here... :-(

[jeremyhu (Jeremy Huddleston Sequoia)]

Replying to vaccari@…:

Hmmm, I repeated the above after reactivating the working MacPorts installation, and _muldi3_s.o shows no difference, so I'm assuming I'm not doing anything useful here... :-(

Yes, the bug is not with the object file. The issue is with ld64 building incorrectly on some systems for some reason.

Please provide the information requested (the preprocessed source code). Providing additional logs showing the failure is not helpful.

[vaccari@…]

I can well be mistaken, as I'm no expert here, but I thought the output of command

sudo clang -E .... -o _muldi3_s.o ...

(full command in comment:91) should be a preprocessed source code, despite its .o extrension, and that is the file I attached. The beginning of that file looks like this

# 1 "libgcc2.c"
# 1 "libgcc2.c" 1
# 1 "<built-in>" 1
# 1 "<built-in>" 3
# 146 "<built-in>" 3
# 1 "<command line>" 1
# 1 "<built-in>" 2
# 1 "libgcc2.c" 2
# 28 "libgcc2.c"
# 1 "../../build/gcc/tconfig.h" 1

# 1 "../../build/gcc/auto-host.h" 1
# 7 "../../build/gcc/tconfig.h" 2

# 1 "../include/ansidecl.h" 1
# 9 "../../build/gcc/tconfig.h" 2
# 29 "libgcc2.c" 2
# 1 "../gcc/tsystem.h" 1
# 45 "../gcc/tsystem.h"
# 1 "/usr/bin/../lib/clang/4.1/include/stddef.h" 1 3 4
# 31 "/usr/bin/../lib/clang/4.1/include/stddef.h" 3 4
typedef __typeof__(((int*)0)-((int*)0)) ptrdiff_t;

typedef __typeof__(sizeof(int)) size_t;

typedef int wchar_t;
# 46 "../gcc/tsystem.h" 2
...
...

This file comes out with no difference on the broken and on the working system.

[vaccari@…]

So, I'm now trying to produce the preprocessed code for macho_relocatable_file.cpp

Found it in

/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_devel_ld64/ld64/work/ld64-133.3/src/ld/parsers

cd there and tried

sudo clang -E -I. -I../../ld -I../../abstraction macho_relocatable_file.cpp -o macho_relocatable_file.cpp.preprocessed

But got error

In file included from macho_relocatable_file.cpp:35:
../../abstraction/MachOFileAbstraction.hpp:290:10: fatal error: 
      'mach-o/arm/reloc.h' file not found
#include <mach-o/arm/reloc.h>

I can only guess some needed configuration is missing when trying clang -E straight from the command line.

I'm willing to help here, but don't want to waste your time either, given I'm quite ignorant on this matter...

[jeremyhu (Jeremy Huddleston Sequoia)]

Replying to vaccari@…:

I can well be mistaken, as I'm no expert here, but I thought the output of command

sudo clang -E .... -o _muldi3_s.o ...

Right, but we don't care about muldi3_s.o. It's not part of ld64. You're just seeing it in your error messages because ld is trying to link that file, but ld is the problem, not muldi3_s.o.

Replying to vaccari@…:

So, I'm now trying to produce the preprocessed code for macho_relocatable_file.cpp

Found it in

/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_devel_ld64/ld64/work/ld64-133.3/src/ld/parsers

cd there and tried

sudo clang -E -I. -I../../ld -I../../abstraction macho_relocatable_file.cpp -o macho_relocatable_file.cpp.preprocessed

But got error

In file included from macho_relocatable_file.cpp:35:
../../abstraction/MachOFileAbstraction.hpp:290:10: fatal error: 
      'mach-o/arm/reloc.h' file not found
#include <mach-o/arm/reloc.h>

I can only guess some needed configuration is missing when trying clang -E straight from the command line.

I'm willing to help here, but don't want to waste your time either, given I'm quite ignorant on this matter...

Look at the build log for ld64 and just replace the '-c -o <output file>' with '-E -o <where you want to store the preprocessed source>' ... Please don't try to figure out a build line on your own because there is something *very particular* going on here, and you need to present me with the exact preprocessed source, not just *any* preprocessed source.

In my log, I see:

/usr/bin/clang++ -Os -O2 -arch x86_64 -I/opt/local/libexec/llvm-3.1/include -DLTO_SUPPORT -Isrc/abstraction -Isrc/ld -Isrc/ld/parsers -I/opt/local/include  -c -o src/ld/parsers/macho_relocatable_file.o src/ld/parsers/macho_relocatable_file.cpp

So I would do:

/usr/bin/clang++ -Os -O2 -arch x86_64 -I/opt/local/libexec/llvm-3.1/include -DLTO_SUPPORT -Isrc/abstraction -Isrc/ld -Isrc/ld/parsers -I/opt/local/include  -E -o ~/Desktop/macho_relocatable_file.preprocessed.cpp src/ld/parsers/macho_relocatable_file.cpp

[vaccari@…]

Finally, I think I got it... added attachments now...

[jeremyhu (Jeremy Huddleston Sequoia)]

vaccari, is that preprocessed source from a working ld64? The OutputFile that you provided does not match the non-working ld.mp.exp2 attached above...

I need good/bad comparisons. The code that you attached looks like it should work (it has the support that is missing in the non-working ld.mp.exp2)

[vaccari@…]

It's a non working installation. I tried right now to build libstdcxx and failed with the usual error

Franco

[vaccari@…]

But please note that I'm not the one who posted ld.mp.exp1 and ld.mp.exp2

[jeremyhu (Jeremy Huddleston Sequoia)]

Can you please attach your (not working) ld?

[neverpanic (Clemens Lang)]

I'm attaching

• a working ld binary
• MacPorts' main.log
• preprocessor results of OutputFile.cpp and macho_relocatable_file.cpp
• ld-configure.h

(I was fooled by a failed build in a different package into thinking my ld64 was broken. Sorry for the noise. The attachment below incorrectly states "cal's broken ld64"!)

[neverpanic (Clemens Lang)]

cal's broken ld64 build, ld binary, ld-configure.h, macho_relocatable_file.cpp and OutputFile.cpp preprocessed and MacPorts' main.log

[sean@…]

Cc Me!

[macosforge@…]

I had this problem too. rebuilding ld64 and libranlib fixed it for me.

[jwhowse4]

Replying to jwhowse4@…:

Replying to jeremyhu@…:

Replying to jwhowse4@…:

Actually as I indicated in my initial reply, under XCode 4.5.0 neither of these examples gives me a working linker. In fact I have tried some other package orderings and so far I can not find an ordering which gives a working linker with XCode 4.5.0. Strangely every ordering gives me a different linker, but none of them work.

Exactly what Xcode version are you using to reproduce this with?

Replying to jwhowse4@…:

Replying to jeremyhu@…:

So I did what I said above, and both versions of ld have the N2ld4tool14DataInCodeAtomI6x86_64EE string (whereas your bad one didn't). Additionally, both seem to link an x86_64 executable just fine.

Ugg... so could you give me the full macports-tst1 and macports-tst2 (ie, build all the way through ld64 rather than stopping before llvm-3.1)? Additionally, please provide the preprocessed source for macho_relocatable_file.cpp and OutputFile.cpp for both the good and bad versions.

I am unclear what you mean by preprocessed source for macho_relocatable_file.cpp and OutputFile.cpp. Also do you want these results even if both versions are bad?

Yes, I want the good and bad versions.

The preprocessed source is the C code that is passed to the compiler after being preprocessed by the C preprocessor. The C preprocessor takes care of the #-directives, macro expansion, etc. You get those results using -E rather than -c.

Eg:

$ clang -c file.c -o file.o  # This will compile file.c and produce an object file
$ clang -E file.c -o file.preprocessed.c # This will save the preprocessed source

You will need to look through the build logs and produce the preprocessed source for the working and broken version.

I am using the latest XCode for Lion from the AppStore which is listed as version 4.5. For this version of XCode there are no good versions, everything I try results in a bad version.

It has taken me a while to regress to XCode 4.4.1 and rerun my previous experiments. In about 2 hours a TAR file should appear in the DropBox that I shared with you previously containing all the information you requested. Please let me know if you are able to get it, and whether you need anything additional. As stated in the included README file things labeled 'tst1' produced a working linker and things labeled 'tst2' produced a broken linker.

[jeremyhu (Jeremy Huddleston Sequoia)]

Replying to jwhowse4@…:

It has taken me a while to regress to XCode 4.4.1 and rerun my previous experiments. In about 2 hours a TAR file should appear in the DropBox that I shared with you previously containing all the information you requested. Please let me know if you are able to get it, and whether you need anything additional. As stated in the included README file things labeled 'tst1' produced a working linker and things labeled 'tst2' produced a broken linker.

Thanks for your help. Does the tarball actually contain everything through 'port install ld64'? I was hoping that just having up to before the 'port install llvm-3.1' would be enough, and I was trying to save you some bandwidth, but based on how finicky this process has been, it would be good if I could see everything.

[jwhowse4]

Replying to jeremyhu@…:

Replying to jwhowse4@…:

It has taken me a while to regress to XCode 4.4.1 and rerun my previous experiments. In about 2 hours a TAR file should appear in the DropBox that I shared with you previously containing all the information you requested. Please let me know if you are able to get it, and whether you need anything additional. As stated in the included README file things labeled 'tst1' produced a working linker and things labeled 'tst2' produced a broken linker.

Thanks for your help. Does the tarball actually contain everything through 'port install ld64'? I was hoping that just having up to before the 'port install llvm-3.1' would be enough, and I was trying to save you some bandwidth, but based on how finicky this process has been, it would be good if I could see everything.

For each of the 2 tests, there is a TAR containing the state before installing llvm and a TAR containing the state after installing ld64. I believe they are appropriately labeled. For each test there is also the preprocessed source for macho_relocatable_file.cpp and OutputFile.cpp as well as copies of the generated linker and the command script I used to obtain the results. For both tests I used the -k option throughout, so the complete build and log directories for all ports are available.

[jeremyhu (Jeremy Huddleston Sequoia)]

Awesome, thanks. Please don't upgrade to XCode 4.5 again as I may have more questions after I look at this.

[jeremyhu (Jeremy Huddleston Sequoia)]

Hmm... your preprocessed source files don't seem to match the build ld. I wonder if there is something in the environment (CPATH?) that is causing your run to be different than the port install run.

Please apply this patch to ld64's Portfile for each -tstX prefix:

Index: Portfile
===================================================================
--- Portfile	(revision 98257)
+++ Portfile	(working copy)
@@ -29,6 +29,12 @@
 
 patchfiles              ld64-version.patch ld64-133-no-CrashReporterClient.h.patch
 
+#compiler.cpath              ""
+#compiler.library_path       ""
+configure.cflags-append     -save-temps
+configure.cxxflags-append   -save-temps
+configure.objcflags-append  -save-temps
+
 # We don't set llvmXX as the default variant on Tiger because it would introduce a
 # dependency cycle as llvm requires apple-gcc42 and ld64 to build correctly.  Users
 # wanting LTO support in ld64 on Tiger can install the +llvm variant after llvm

then for each prefix do:

sudo port -v uninstall ld64
port -v install ld64 +llvm31

Then send me the new ld64 workdirs (no need to send me the whole thing, just <prefix>/var/macports/build/*ld64

[jeremyhu (Jeremy Huddleston Sequoia)]

After doing the above, I'm curious if uncommenting the two lines above (specifically cpath) have any effect. It feels like I'm grasping at straws, but the mismatch between your preprocessed source and the build ld (and its object files in its workdir) is suspicious ... it makes me think that there is probably something in the environment tripping us up because both versions of the preprocessed source look good.

[george@…]

Cc Me!

[jwhowse4]

Replying to jeremyhu@…:

Hmm... your preprocessed source files don't seem to match the build ld. I wonder if there is something in the environment (CPATH?) that is causing your run to be different than the port install run.

Please apply this patch to ld64's Portfile for each -tstX prefix:

Index: Portfile
===================================================================
--- Portfile	(revision 98257)
+++ Portfile	(working copy)
@@ -29,6 +29,12 @@
 
 patchfiles              ld64-version.patch ld64-133-no-CrashReporterClient.h.patch
 
+#compiler.cpath              ""
+#compiler.library_path       ""
+configure.cflags-append     -save-temps
+configure.cxxflags-append   -save-temps
+configure.objcflags-append  -save-temps
+
 # We don't set llvmXX as the default variant on Tiger because it would introduce a
 # dependency cycle as llvm requires apple-gcc42 and ld64 to build correctly.  Users
 # wanting LTO support in ld64 on Tiger can install the +llvm variant after llvm

then for each prefix do:

sudo port -v uninstall ld64
port -v install ld64 +llvm31

Then send me the new ld64 workdirs (no need to send me the whole thing, just <prefix>/var/macports/build/*ld64

After doing the above, I'm curious if uncommenting the two lines above (specifically cpath) have any effect. It feels like I'm grasping at straws, but the mismatch between your preprocessed source and the build ld (and its object files in its workdir) is suspicious ... it makes me think that there is probably something in the environment tripping us up because both versions of the preprocessed source look good.

I have applied the patch and reinstalled ld64 for both tst1 and tst2 with both compiler.XX lines commented out and with them not commented out. So I am attaching four TAR files. The 2 with tst1 in the name correspond to the procedure that produced the working linker, the 2 with tst2 in the name correspond to the procedure that produced the broken linker. The 2 TAR files with no_cpath in the name have the compiler.XX lines commented out, the 2 TAR files with cpath in the name have those two lines uncommented. However, I have serious concerns about the utility of these results because in both of my two test installations I get a different linker every time I run the command pair

port -v uninstall ld64
port -v -k install ld64 +llvm31

with the original Portfiles. By different I mean the executable named 'ld' is a different size. Furthermore I can run this command pair over and over and the size of 'ld' is different each time. There appear to be 10 to 20 possible sizes but I see no pattern to the order of appearance of the various sizes. So this build process, while it must be deterministic, appears to be an example of deterministic chaos in many ways.

[mike@…]

Cc Me!

[jwhowse4]

Actually my command sequence in the previous post should have read as follows.

port -v uninstall ld64
port -v clean ld64
port -v -k install ld64 +llvm31

[ryandesign (Ryan Carsten Schmidt)]

Has duplicate #36596.

[cs@…]

Cc Me!

[billmag687@…]

Cc Me!

[jeremyhu (Jeremy Huddleston Sequoia)]

I think r98868 should fix this.

[vaccari@…]

Yes, it's working here now. Successfully installed libstdcxx. Thanks!

[jwhowse4]

Replying to jeremyhu@…:

I think r98868 should fix this.

This fix appears to correct all the issues I saw on my system. Thank you very much for keeping after this problem!

[jeremyhu (Jeremy Huddleston Sequoia)]

Replying to jwhowse4@…:

Replying to jeremyhu@…:

I think r98868 should fix this.

This fix appears to correct all the issues I saw on my system. Thank you very much for keeping after this problem!

Thanks for your help. I'm sorry it took a month and a half to figure out.