ld64 should symlink rather than copy ld and rebase on darwin > 10

[howarth@…]

The logic of the section handling darwin > 10 in the ld64 Portfile is flawed. By copying the ld and rebase files from /usr/bin into /opt/local/bin, MacPorts is locking the user into a snapshot of the Xcode currently installed when the ld64 package is built. The ld64 package should be creating symlinks to these files instead of copying them.

[howarth@…]

Portfile.diff for ld64 to use symlinks on darwin > 10

[howarth@…]

Cc Me!

[mfeiri]

The current practice for darwin >10 is really just a safety measure because I assumed it could be problematic to use e.g. ld64-97 in a future OS version. I dont have access to pre-release versions of macosx but I assume that ld64-123 as sen in Xcode 4.0 should work fine on darwin 11. I will change the port to use our own ld64 on darwin 11 instead of using a version provided by Xcode.

I think I tested the symlink method in the past and found that ld would pick up the wrong libLTO.dylib (Apples version in /usr/lib/ instead of our own version in ${prefix}/lib/) when symlinking instead of copying the executable. See #19679 for reference. But I just tested the symlink method again and it now seems to work as intended. Maybe thats because the default libLTO.dylib is now linked statically? Anyway, I will happily switch to using the symlink method for darwin >11. Or should I just remove this method of handling unknown darwin releases?

While we are talking about ld64 I noticed that this port ends up replacing the systems ld. This is not how I intended this port to work. I will introduce a post-destroot phase and rename ld to ld-mp. Ports that use LTO should take care to use ld-mp instead of the default ld to be sure to have a matching version of libLTO used by ld. See the ld symlink in the clang port for reference. We will have to make sure that e.g. llvm-gcc42 and de-gcc45 will correctly handle this change, probably using the "--with-ld" configuration option.

[howarth@…]

From my conversations with the Apple linker developer, we can simply access the desired libLTO.dylib using the linker as a symlink in ${prefix}/bin while the llvm libLTO.dylib resides in $(prefix}/lib. There should be no need to use anything more than symlinks to /usr/bin/ld for this purpose. It also insures that we don't desynchronize the linker from the assembler which could cause subtle problems.

[mfeiri]

Interesting thought about assembler desynchronisation... Clang has its own internal assembler these days, so I didnt think about this issue. I really really want to _reduce_ reliance on Xcode but I dont want to reopen the entire (od)cctools can of worms either. I do admit that, now that the symlink method allows us to use our own libLTO.dylib, it seems tempting to use the symlink method exclusively. I'll have to think about that.

One option would be to support all three combinations (Xcode ld using Xcode libLTO, Xcode ld using MacPorts libLTO, MacPorts ld using MacPorts libLTO) by installing our own ld64 as "ld-mp" and setting up a symlink to Xcode's ld named "ld-mp-xc". The regular unmodified "ld" would continue to be accessible as usual. But that seems rather clumsy.

[cooljeanius (Eric Gallager)]

Cc Me!

[kencu (Ken)]

nearly a decade old. The way ld64 and cctools works on MacPorts has been embedded by Jeremy and is no longer open to major changes in implementation after all these years.