[MacPorts] #36026: ld64 sometimes builds wrong which causes other software to fail to build

[MacPorts]

#36026: ld64 sometimes builds wrong which causes other software to fail to build
-------------------------+------------------------
  Reporter:  jwhowse4@…  |      Owner:  jeremyhu@…
      Type:  defect      |     Status:  new
  Priority:  Normal      |  Milestone:
 Component:  ports       |    Version:  2.1.2
Resolution:              |   Keywords:
      Port:  ld64        |
-------------------------+------------------------

Comment (by jwhowse4@…):

 Replying to [comment:80 jwhowse4@…]:
 > Replying to [comment:79 jeremyhu@…]:
 > > Replying to [comment:77 jwhowse4@…]:
 > > > Actually as I indicated in my initial reply, under XCode 4.5.0
 neither of these examples gives me a working linker.  In fact I have tried
 some other package orderings and so far I can not find an ordering which
 gives a working linker with XCode 4.5.0.  Strangely every ordering gives
 me a different linker, but none of them work.
 > >
 > > Exactly what Xcode version are you using to reproduce this with?
 > >
 > >
 > > Replying to [comment:78 jwhowse4@…]:

 > > > Replying to [comment:76 jeremyhu@…]:
 > > > > So I did what I said above, and both versions of ld have the
 N2ld4tool14DataInCodeAtomI6x86_64EE string (whereas your bad one didn't).
 Additionally, both seem to link an x86_64 executable just fine.
 > > > >
 > > > > Ugg... so could you give me the full macports-tst1 and macports-
 tst2 (ie, build all the way through ld64 rather than stopping before
 llvm-3.1)?  Additionally, please provide the preprocessed source for
 macho_relocatable_file.cpp and OutputFile.cpp for both the good and bad
 versions.
 > > >
 > > > I am unclear what you mean by preprocessed source for
 macho_relocatable_file.cpp and OutputFile.cpp.  Also do you want these
 results even if both versions are bad?
 > >
 > > Yes, I want the good and bad versions.
 > >
 > > The preprocessed source is the C code that is passed to the compiler
 after being preprocessed by the C preprocessor.  The C preprocessor takes
 care of the #-directives, macro expansion, etc.  You get those results
 using -E rather than -c.
 > >
 > > Eg:
 > >
 > > {{{
 > > $ clang -c file.c -o file.o  # This will compile file.c and produce an
 object file
 > > $ clang -E file.c -o file.preprocessed.c # This will save the
 preprocessed source
 > > }}}
 > >
 > > You will need to look through the build logs and produce the
 preprocessed source for the working and broken version.
 >
 > I am using the latest XCode for Lion from the AppStore which is listed
 as version 4.5.  For this version of XCode there are no good versions,
 everything I try results in a bad version.

 It has taken me a while to regress to XCode 4.4.1 and rerun my previous
 experiments.  In about 2 hours a TAR file should appear in the DropBox
 that I shared with you previously containing all the information you
 requested.  Please let me know if you are able to get it, and whether you
 need anything additional.  As stated in the included README file things
 labeled 'tst1' produced a working linker and things labeled 'tst2'
 produced a broken linker.

-- 
Ticket URL: <https://trac.macports.org/ticket/36026#comment:105>
MacPorts <http://www.macports.org/>
Ports system for Mac OS