mosh @1.3.2_1+perl5_26 fails to build

[tehcog (tehcog)]

Please see attached log...

xxXXxx::xxXXxx { ~ }-> sudo port upgrade mosh
Password:
--->  Scanning binaries for linking errors
--->  Found 2 broken files, matching files to ports
--->  Found 1 broken port, determining rebuild order
You can always run 'port rev-upgrade' again to fix errors.
The following ports will be rebuilt: mosh @1.3.2+perl5_26
Continue? [Y/n]:
--->  Computing dependencies for mosh
--->  Cleaning mosh
--->  Scanning binaries for linking errors
--->  Found 2 broken files, matching files to ports
--->  Found 1 broken port, determining rebuild order
--->  Rebuilding in order
     mosh @1.3.2 +perl5_26
--->  Computing dependencies for mosh
--->  Fetching distfiles for mosh
--->  Verifying checksums for mosh
--->  Extracting mosh
--->  Configuring mosh
--->  Building mosh
Error: Failed to build mosh: command execution failed
Error: See /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_net_mosh/mosh/main.log for details.
Error: rev-upgrade failed: Error rebuilding mosh
Error: Follow https://guide.macports.org/#project.tickets to report a bug.

[tehcog (tehcog)]

main.log

[mf2k (Frank Schima)]

Looks like it is related to protobuf3-cpp. Is that updated to the latest version?

[blair (Blair Zajac)]

I can confirm the build failure.

I just reverted the protobuf3-cpp commit (without bumping the epoch).

[tobypeterson]

Looks like this is on a really, really old version of macOS, guess it doesn't support newer C++ features. Dumb to revert because of that, but whatever.

[tobypeterson]

In 333fbc8da2fe7eddf2848b83e773322f4d9cde1c/macports-ports (master):

mosh: add cxx11 PortGroup, should resolve #57012

[tobypeterson]

Adopted cxx11 PortGroup in mosh, updated protobuf3-cpp again. If other ports break, please fix them - don't let old OS versions hold us back.

[kencu (Ken)]

The issue here is that protobuf3-cpp now REQUIRES all software using it to be built with at least -std=c++11. Only the most recent clang versions default to that, so that flag will need to be added to all builds.

In addition to the PG cxx11 1.1, you need

configure.cxxflags-append -std=c++11

and then it builds.

[l2dy (Zero King)]

Replying to tobypeterson:

Adopted cxx11 PortGroup in mosh, updated protobuf3-cpp again. If other ports break, please fix them - don't let old OS versions hold us back.

You need to revbump all protobuf3-cpp dependents because soname changed from libprotobuf.15.dylib to libprotobuf.17.dylib. People using binary archives would have to rebuild them locally if you don't bump revisions.

[kencu (Ken)]

Revbumping alone will not work, I don't think. mosh needed -std=c++11 added to the build line.

Do any XCode clangs default to c++11 now? Only the very most recent of the OSS clangs do.

[ken-cunningham-webuse]

In adc347a6e426b853d936f6ba0ee636dc1e1aba5d/macports-ports (master):

mosh: build with c++11

protobuf3-cpp requires c++11 now
closes: #57012

[tobypeterson]

Unfortunate that a non-major version updated the dylib version. Makes me think they're not doing library versioning properly.

[tobypeterson]

Updated py-protobuf3 and protobuf-c, bumped revisions on 7 other ports

[blair (Blair Zajac)]

Thanks for fixing the port and dependent ports.

I think it's better to revert and then fix the issues, as this pushes the work on the committer who did the upgrade instead of dependent ports, it's not the job of the dependent port maintainers to fix a port broken by another port. Also, a fast revert leaves the port tree in a healthy state.

[kencu (Ken)]

Thanks for fixing the port and dependent ports.

Most of the dependent ports are still broken. Only the ones that already were building as c++11 were fixed by the revbump.

The rest need to be rejigged to build as c++11 before they will be fixed. With some, this is easy (eg mosh). With others, (eg ostinato) not so easy, it turns out.

[quentinmit (Quentin Smith)]

It makes me sad that every port is going to have to change its build process as a result of changes in protobuf3-cpp. Is there any way for this configuration to automatically happen as a result of the dependency? e.g. via a pkg-config file or a #pragma in the protobuf headers?

If not, the commit LGTM as a workaround.

[tobypeterson]

ostinato needs to be fixed anyway, since qt4 can't even be installed now.

[kencu (Ken)]

qt4 works on every system from 10.4 to 10.13.