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.

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

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.

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.

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.

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.

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:

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:

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 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.

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.

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.

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?

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 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'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?

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?

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.

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.

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.

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.

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!

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.

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...

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.

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"

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.

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.

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.

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.

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?

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.

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.

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.

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.

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.

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

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.