[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:109 jeremyhu@…]:
 > Hmm... your preprocessed source files don't seem to match the build ld.
 I wonder if there is something in the environment (CPATH?) that is causing
 your run to be different than the port install run.
 >
 > Please apply this patch to ld64's Portfile for each -tstX prefix:
 >
 > {{{
 > Index: Portfile
 > ===================================================================
 > --- Portfile  (revision 98257)
 > +++ Portfile  (working copy)
 > @@ -29,6 +29,12 @@
 >
 >  patchfiles              ld64-version.patch ld64-133-no-
 CrashReporterClient.h.patch
 >
 > +#compiler.cpath              ""
 > +#compiler.library_path       ""
 > +configure.cflags-append     -save-temps
 > +configure.cxxflags-append   -save-temps
 > +configure.objcflags-append  -save-temps
 > +
 >  # We don't set llvmXX as the default variant on Tiger because it would
 introduce a
 >  # dependency cycle as llvm requires apple-gcc42 and ld64 to build
 correctly.  Users
 >  # wanting LTO support in ld64 on Tiger can install the +llvm variant
 after llvm
 > }}}
 >
 > then for each prefix do:
 > {{{
 > sudo port -v uninstall ld64
 > port -v install ld64 +llvm31
 > }}}
 >
 > Then send me the new ld64 workdirs (no need to send me the whole thing,
 just <prefix>/var/macports/build/*ld64

 > After doing the above, I'm curious if uncommenting the two lines above
 (specifically cpath) have any effect. It feels like I'm grasping at
 straws, but the mismatch between your preprocessed source and the build ld
 (and its object files in its workdir) is suspicious ... it makes me think
 that there is probably something in the environment tripping us up because
 both versions of the preprocessed source look good.

 I have applied the patch and reinstalled ld64 for both tst1 and tst2 with
 both compiler.XX lines commented out and with them not commented out.  So
 I am attaching four TAR files.  The 2 with tst1 in the name correspond to
 the procedure that produced the working linker, the 2 with tst2 in the
 name correspond to the procedure that produced the broken linker.  The 2
 TAR files with no_cpath in the name have the compiler.XX lines commented
 out, the 2 TAR files with cpath in the name have those two lines
 uncommented.  However, I have serious concerns about the utility of these
 results because in both of my two test installations I get a different
 linker every time I run the command pair

 {{{
 port -v uninstall ld64
 port -v -k install ld64 +llvm31
 }}}

 with the original Portfiles.  By different I mean the executable named
 'ld' is a different size.  Furthermore I can run this command pair over
 and over and the size of 'ld' is different each time.  There appear to be
 10 to 20 possible sizes but I see no pattern to the order of appearance of
 the various sizes.  So this build process, while it must be deterministic,
 appears to be an example of deterministic chaos in many ways.

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