[MacPorts] #29173: ld64 should symlink rather than copy ld and rebase on darwin > 10

[MacPorts]

#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