[MacPorts] #62656: rust @1.51.0 does not build on 10.9: Dyld: lazy symbol binding failed: Symbol not found: _linkat (OS 10.9)

[MacPorts]

#62656: rust @1.51.0 does not build on 10.9: Dyld: lazy symbol binding failed:
Symbol not found: _linkat (OS 10.9)
-------------------------+-----------------------
  Reporter:  cave-canem  |      Owner:  (none)
      Type:  defect      |     Status:  new
  Priority:  Normal      |  Milestone:
 Component:  ports       |    Version:  2.6.99
Resolution:              |   Keywords:  mavericks
      Port:  rust        |
-------------------------+-----------------------

Comment (by Wowfunhappy):

 Replying to [comment:19 kencu]:
 > Replying to [comment:17 cave-canem]:
 > > Thanks Ken, I knew about this, so I wrote:
 > > >> "As a possible solution, can you add a static linking variant to
 the rust port?"
 >

 > The symbols are in the executable (which is already 99% statically
 linked), and mortals can't really force them in there. (I actually think
 you can do it, with a decompiler/dissassembler, but ... not us).

 I read this and my first thought was "can't you just use
 install_name_tool"?

 I wanted to play around, so I booted a clean 10.9 VM and built
 libMacportsLegacySupport.dylib. Then, I used optool to add
 `libSystem.B.dylib` as a sub-library of `libMacportsLegacySupport.dylib`:

 {{{
 optool install -c reexport -p /usr/lib/libSystem.B.dylib -t
 ~/Desktop/libMacportsLegacySupport.dylib
 }}}

 (I'm sure there's a way to do this at compile-time without optool, but
 I've been using optool.)

 Next, I installed rust using rustup and went to create a new project.

 {{{
 curl -sSf https://sh.rustup.rs | sh
 source $HOME/.cargo/env`
 cargo new hello-rust
 cd hello-rust/
 cargo new
 cargo run
 }}}

 Of course, `cargo run` gave me the expected `Symbol not found: _linkat`
 error. So I tried to use install_name_tool to swap out libSystem for
 LegacySupport:

 `install_name_tool -change /usr/lib/libSystem.B.dylib
 ~/Desktop/libMacportsLegacySupport.dylib /Users/jonathan/.cargo/bin/cargo`

 Unfortunately, this yielded:

 {{{
 /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/install_name_tool:
 object: /Users/jonathan/.cargo/bin/cargo malformed object (unknown load
 command 10)
 }}}

 I'm not sure if this is the issue you ran into Ken, but it's not caused by
 some special Rust magic—Mavericks's `install_name_tool` was just too old.
 I copied the cargo binary to a 10.13 VM, re-ran the command, and copied
 the binary back to 10.9. In hindsight, I'm pretty sure I could have just
 installed an updated copy of the cctools port instead...

 I had to also do the swap out on a couple of other binaries (but these all
 worked from within Mavericks):

 {{{
 install_name_tool -change /usr/lib/libSystem.B.dylib
 ~/Desktop/libMacportsLegacySupport.dylib
 /Users/jonathan/.rustup/toolchains/stable-x86_64-apple-darwin/bin/../lib
 /libstd-349f286494d73b18.dylib
 install_name_tool -change /usr/lib/libSystem.B.dylib
 ~/Desktop/libMacportsLegacySupport.dylib
 /Users/jonathan/.rustup/toolchains/stable-x86_64-apple-darwin/bin/cargo

 }}}

 After that, `cargo run` started my hello world program without any
 additional incantations.

 Now, what I wasn't able to do was install rav1e with cargo, but I suspect
 I just need to swap out libSystem for legacySupport in more binaries... I
 think? And if so, I don't think there's anything that would be nuts so to
 do automatically...

 ---

 P.S. To make cargo work, I installed https://jonathanalland.com/legacy-
 mac-proxy.html (disclaimer: my own package) and then set the environment
 variable `https_proxy` to `localhost:3128`. I really need to add this to
 the readme in my package—a lot of command line programs, including curl,
 won't use the proxy unless this is set.

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