Changes between Initial Version and Version 1 of Ticket #36910, comment 16


Ignore:
Timestamp:
Dec 15, 2012, 9:07:14 AM (11 years ago)
Author:
anddam (Andrea D'Amore)
Comment:

Legend:

Unmodified
Added
Removed
Modified

  • Ticket #36910, comment 16

    initial v1  
    1 '''Jeremy''': with all packages updated to HEAD, I uninstalled all of them, installed cctools-headers and ld64, switched the ld binary with my XC 4.5.1 provided ld that says
     1'''Jeremy''': after updating all ports' directories to HEAD, I uninstalled ld64 and cctools-headers that in last test were at 99184, installed those at HEAD, renamed /opt/local/bin/ld and symlinked it to the one provided by Xcode 4.5.1 command line tools.
     2
     3At this point I had an updated set of ports with the active ld being the one provided by Xcode, but cctools, apple-gcc42 and virtualbox had been built with ld from r99184 so I rebuilt them in order.
     4
     5Here's output of /usr/bin/ld/:
    26{{{
    37/o/l/bin> /usr/bin/ld -v
    … …  
    610LTO support using: LLVM version 3.1svn, from Apple Clang 4.1 (build 421.11.66)
    711}}}
    8 and built cctools, apple-gcc42 and virtualbox in this order.
    912
    10 The produced virtualbox port '''doesn't work''' giving the same error as this ticket's description reports.
    11 Unluckily I need to use vbox so for now I'm just reverting ld64 and lock it that way.
     13The resulting virtualbox port '''doesn't work''' giving the same error as this ticket's description reports.
     14Hope this helps answering your question about the two different scenarios, I guess the next test should be installing Xcode 4.4 command line tools and try again to see if the bug has to be reported upstream to Apple.
     15Unluckily I need to use vbox so for now I'm just reverting ld64 and lock it that way in my local repo as this is kinda time consuming.