cargo: 0.61.1 fails to build for 10.12 and earlier

[mascguy (Christopher Nielsen)]

This port is broken for a wide swath of users, despite being a fairly critical toolchain component. Please review the build status within 12 hours after updating, to be sure it builds successfully everywhere!

​https://ports.macports.org/port/cargo/builds/

At least on 10.12, the issue appears to potentially be related to OpenSSL and/or OpenSSH:

/_opt_bblocal_var_buildworker_ports_build_ports_devel_cargo/cargo/work/cargo-0.61.1/target/x86_64-apple-darwin/release/deps/cargo-5b31aa106374ee84" "-Wl,-dead_strip" "-nodefaultlibs"
  = note: Undefined symbols for architecture x86_64:
            "_EVP_PKEY_id", referenced from:
                __libssh2_ed25519_new_private_frommemory in liblibssh2_sys-e53ed92cbfc19e85.rlib(openssl.o)
                __libssh2_pub_priv_keyfile in liblibssh2_sys-e53ed92cbfc19e85.rlib(openssl.o)
                __libssh2_pub_priv_keyfilememory in liblibssh2_sys-e53ed92cbfc19e85.rlib(openssl.o)
          ld: symbol(s) not found for architecture x86_64
          clang: error: linker command failed with exit code 1 (use -v to see invocation)

Members: Please do NOT downgrade the severity of this, as it's a high-priority issue that needs to be addressed ASAP. Thanks!

[herbygillot (Herby Gillot)]

I think the only way we're going to avoid recurring issues like these is to make a concerted effort to provide a test matrix of all macOS versions for Github pull requests. Either that, or some alternate testing branch that can run on the actual buildbots.

[mascguy (Christopher Nielsen)]

Replying to herbygillot:

I think the only way we're going to avoid recurring issues like these is to make a concerted effort to provide a test matrix of all macOS versions for Github pull requests. Either that, or some alternate testing branch that can run on the actual buildbots.

There's a simple solution: Create a 2nd port, cargo-devel, and update that first. We use that practice extensively elsewhere, and that solves this issue once-and-for-all.

[tehcog (tehcog)]

mavericks main.log

[tehcog (tehcog)]

Looks the same for mavericks. See attached log.

[herbygillot (Herby Gillot)]

There's a simple solution: Create a 2nd port, cargo-devel, and update that first. We use that practice extensively elsewhere, and that solves this issue once-and-for-all.

Fair point. I'm trying to get a Sierra environment running in a VM on an Intel Mac locally, but it's been difficult finding an installer that works. Any pointers?

[mascguy (Christopher Nielsen)]

Replying to herbygillot:

There's a simple solution: Create a 2nd port, cargo-devel, and update that first. We use that practice extensively elsewhere, and that solves this issue once-and-for-all.

Fair point. I'm trying to get a Sierra environment running in a VM on an Intel Mac locally, but it's been difficult finding an installer that works. Any pointers?

There was some discussion about this on the mailing lists - can't remember whether it was Dev or Users - within the past 2-ish years.

But as a starting point, Google for sucatalog, along with 10.12 and other related keywords. Though @kencu might have some pointers too.

As for me, still not fully caffeinated, so I can't recall what I did. But assuming Ken and others don't reply first, I'll see what I can dig up!

[mascguy (Christopher Nielsen)]

Herby, here's one place that might give you what you need:

​https://osxdaily.com/where-download-macos-installers/

[Christopher Nielsen <mascguy@…>]

In 432e2f2e2e3e5d1df430e353e25fc630d4734fc2/macports-ports (master):

cargo: revert to 0.61.0, until builds are fixed for 10.12 and earlier
See: #65011

[reneeotten (Renee Otten)]

why not only reverting this change on systems where it doesn’t build?

[mascguy (Christopher Nielsen)]

Replying to reneeotten:

why not only reverting this change on systems where it doesn’t build?

Hey Renee, I considered that, but didn't want to over-complicate this: Ultimately we need to stop the bleeding ASAP, as a not-insignificant number of dependent builds have been blocked due to this issue. (In addition to user frustration, due to a foundational port failing to build for 10.12 and earlier.)

Plus it's a simple matter of time, as my professional work responsibilities limit my MacPorts-related time during the day.

Another consideration, is that we're only reverting a minor release bump. If it was a major release, that would change the equation.

Does that make sense?

[MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)]

I believe it is a bit difficult to get Rust to look in the right place for OpenSSL.
In the current ​pull request, it is handled in the rust PG.

The current problem is that
MACPORTS_LEGACY_SUPPORT_LDFLAGS=-L/opt/local/lib -lMacportsLegacySupport
places /opt/local/lib very high in the search order for libraries.
So -lcrypto finds /opt/local/lib/libcrypto.dylib instead of the intended /opt/local/libexec/openssl11/lib/libcrypto.dylib.

[mascguy (Christopher Nielsen)]

All, I've forced rebuilds for all ports directly dependent on cargo, for 10.12 and earlier.

Since this doesn't cover dependents of those, more will need to be done. But it's a good first step.

More to follow, once those rebuilds have completed.

[mascguy (Christopher Nielsen)]

Reducing priority to normal, since this is no longer a blocking issue.

[MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)]

In dc6a80cd529d8227dfcfbe5981d97e1202beb5eb/macports-ports (master):

cargo: use new rust PG

Support for older systems is added.
Support for 32-bit and universal builds is restored.
The correct OpenSSL should also be found on all systems.
See #65011