#29173: lld64 should symlink rather than copy ld and rebase on darwin > 10 --------------------------------------+------------------------------------- Reporter: howarth@… | Owner: mfeiri@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 1.9.2 Keywords: | Port: ld64 --------------------------------------+------------------------------------- Changes (by ryandesign@…): * keywords: devel => * owner: macports-tickets@… => mfeiri@… * cc: howarth@… (removed) -- Ticket URL: <https://trac.macports.org/ticket/29173#comment:2> MacPorts <http://www.macports.org/> Ports system for Mac OS

#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

#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 --------------------------------------+------------------------------------- Comment(by 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. -- Ticket URL: <https://trac.macports.org/ticket/29173#comment:6> MacPorts <http://www.macports.org/> Ports system for Mac OS