[MacPorts] #63333: cargo @0.54.0_1 fails to build some crates on 10.9

[MacPorts]

#63333: cargo @0.54.0_1 fails to build some crates on 10.9
----------------------------------------+-------------------------
  Reporter:  fhgwright                  |      Owner:  herbygillot
      Type:  defect                     |     Status:  assigned
  Priority:  Normal                     |  Milestone:
 Component:  ports                      |    Version:  2.7.1
Resolution:                             |   Keywords:
      Port:  cargo, rust-compiler-wrap  |
----------------------------------------+-------------------------

Comment (by fhgwright):

 Requiring everything built with rust to be built as a port would be
 extremely onerous, but fortunately not necessary.  The fact that the
 compiles succeed indicates that the compiler wrapper is successfully
 causing the `legacy-support` headers to be injected, and the only problem
 is that there isn't similar injection of the `legacy-support` library into
 the linking.

 The otool -L for the final executable from this is:
 {{{
 MacPro:ll-cli fw$ otool -L ../target/release/library-loader-cli
 ../target/release/library-loader-cli:
 /System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices
 (compatibility version 1.0.0, current version 59.0.0)
         /System/Library/Frameworks/Security.framework/Versions/A/Security
 (compatibility version 1.0.0, current version 55471.14.40)
 /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation
 (compatibility version 150.0.0, current version 855.17.0)
         /opt/local/lib/libMacportsLegacySystem.B.dylib (compatibility
 version 1.0.0, current version 1.0.3)
         /usr/lib/libresolv.9.dylib (compatibility version 1.0.0, current
 version 1.0.0)
         /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
 version 1197.1.1)
         /usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current
 version 7.0.0)
 }}}
 However, I don't think the symlink kludge is the right fix.  Presumably
 the raison d'être for  `libMacportsLegacySystem.B.dylib` is to provide a
 minimal way (and the quickest way for a test) to insert the library
 support, but the minimal way isn't necessarily the best way.  It would be
 better just to add the appropriate linker arguments for the extra library.
 Perhaps this would mean a "linker wrapper" in addition to the compiler
 wrapper.

 With an added library, there would be the issue of whether to use the
 static or dynamic version.  I think static makes more sense in this
 context, particularly since it would mean not adding anything to programs
 that don't actually use any `legacy-support` functions.

 Although I referenced `cargo` in the summary, this is probably really an
 issue with `rust` itself.  One would like builds to work correctly
 regardless of whether `rustc` is invoked directly or via `cargo`.  I'm too
 new to `rust` to know off the top of my head how to see whether this is
 already the case for the includes.

-- 
Ticket URL: <https://trac.macports.org/ticket/63333#comment:10>
MacPorts <https://www.macports.org/>
Ports system for macOS