#29173: ld64 should symlink rather than copy ld and rebase on darwin > 10 --------------------------------------+------------------------------------- Reporter: howarth@… | Owner: mfeiri@… Type: defect | Status: assigned Priority: Normal | Milestone: Component: ports | Version: 1.9.2 Keywords: | Port: ld64 --------------------------------------+------------------------------------- Changes (by mfeiri@…): * status: new => assigned Comment: 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. -- Ticket URL: <https://trac.macports.org/ticket/29173#comment:4> MacPorts <http://www.macports.org/> Ports system for Mac OS