Opened 6 years ago

Closed 6 years ago

#56551 closed defect (fixed)

broken ports due to cxx_stdlib mismatch

Reported by: EJFielding (Eric Fielding) Owned by:
Priority: Normal Milestone:
Component: ports Version: 2.5.0
Keywords: Cc: Schamschula (Marius Schamschula), seanfarley (Sean Farley), michaelld (Michael Dickens), mamoll (Mark Moll), hapaguy (Brian Kurt Fujikawa), majoc-at-astro (majoc-at-astro)
Port: TeXShop4 py27-scipy hdf5 SuiteSparse

Description

I updated my MacPorts to 2.5.0 using the usual port selfupdate and then ran port upgrade outdated. The upgrade seemed to go well, but at the end it checked for broken ports and found three but did not try to do anythng to fix them. I tried running "port rev-upgrade" but that also did not fix the broken ports. These are the broken ports:

port rev-upgrade
--->  Scanning binaries for linking errors
--->  No broken files found.
--->  Found 3 broken ports:
     TeXShop4 @4.01
     py27-scipy @1.1.0 +gcc49
     hdf5 @1.10.2 +cxx+gcc7+hl

I tried uninstalling and installing again the hdf5 port, but it still stayed broken even after rebuilding. I can't tell if this is a problem with the new port version or with the individual ports.

Change History (20)

comment:1 Changed 6 years ago by jmroot (Joshua Root)

Cc: Schamschula seanfarley michaelld mamoll added
Port: TeXShop4 py27-scipy hdf5 added

If you run rev-upgrade with the -d option it will show you why the ports are considered broken. It's likely to be the new check for whether ports are linked with the C++ standard library that they say they are.

comment:2 Changed 6 years ago by EJFielding (Eric Fielding)

Thanks for the hint. You are right. Those three ports seem to be linked to the libstdc++ library. There were a lot of other debug output lines that did not seem relevant.

DEBUG: Ignoring loadcommand containing @rpath in /opt/local/lib/rustlib/x86_64-apple-darwin/lib/libterm-08da937915c30bc0.dylib
DEBUG: Ignoring loadcommand containing @rpath in /opt/local/lib/rustlib/x86_64-apple-darwin/lib/libtest-6a429b3fcf5acfff.dylib
DEBUG: Ignoring loadcommand containing @rpath in /opt/local/lib/rustlib/x86_64-apple-darwin/lib/libtest-6a429b3fcf5acfff.dylib
DEBUG: skipping ppc in /opt/local/share/cmake-3.11/Modules/CPack.OSXScriptLauncher.in since this system can't run it anyway
--->  No broken files found.
TeXShop4 is using libstdc++ (this installation is configured to use libc++)
py27-scipy is using libstdc++ (this installation is configured to use libc++)
hdf5 is using libstdc++ (this installation is configured to use libc++)
--->  Found 3 broken ports:
     TeXShop4 @4.01 
     py27-scipy @1.1.0 +gcc49
     hdf5 @1.10.2 +cxx+gcc7+hl
DEBUG: Checking time since last reclaim run

So is this something that I need to fix or do I ignore it?

comment:3 Changed 6 years ago by jmroot (Joshua Root)

It's something that the port maintainers need to fix. However the ports are no more broken than they were before.

comment:4 Changed 6 years ago by Schamschula (Marius Schamschula)

Port: SuiteSparse added
Version 0, edited 6 years ago by Schamschula (Marius Schamschula) (next)

comment:5 Changed 6 years ago by michaelld (Michael Dickens)

SuiteSparse needs some work to see if a modern version works with Octave. I'll try to work on that along with this issue "soonish" (for SS & SciPy).

comment:6 Changed 6 years ago by jmroot (Joshua Root)

FTR a rev-bump alone won't fix this. If you change configure.cxx_stdlib to match what the port is already doing, you don't need to rev bump. If you fix the port to use the specified stdlib, you do need to rev bump because the installed files change. The latter is preferable, but the former is acceptable as long as the port doesn't use or provide any C++ libraries from/to other things.

comment:7 Changed 6 years ago by mf2k (Frank Schima)

@EJFielding: A little off-topic, but why are you using an ancient version of gcc (gcc49) with py27-scipy? You should use the same gcc variant for all of your scientific ports. Use gcc7 like you did for hdf5.

comment:8 Changed 6 years ago by hapaguy (Brian Kurt Fujikawa)

Cc: hapaguy added

comment:9 Changed 6 years ago by jmroot (Joshua Root)

Summary: port release 2.5.0 leaving broken portsbroken ports due to cxx_stdlib mismatch

comment:10 Changed 6 years ago by jmroot (Joshua Root)

How many of these are still broken after rev-upgrading with 2.5.1?

comment:11 in reply to:  10 Changed 6 years ago by EJFielding (Eric Fielding)

Two are still broken

 port rev-upgrade
--->  Scanning binaries for linking errors
--->  No broken files found.
--->  Found 2 broken ports:
     hdf5 @1.10.2 +cxx+gcc7+hl
     py27-scipy @1.1.0 +gcc7

Replying to jmroot:

How many of these are still broken after rev-upgrading with 2.5.1?

comment:12 Changed 6 years ago by jmroot (Joshua Root)

Even after letting rev-upgrade reinstall them?

comment:13 in reply to:  12 Changed 6 years ago by EJFielding (Eric Fielding)

On my 10.12.6 Mac, port rev-upgrade does not attempt to reinstall the broken ports under 2.5.0 or 2.5.1.

comment:14 Changed 6 years ago by jmroot (Joshua Root)

You probably have revupgrade_mode set to report in your macports.conf then. You'll either have to change it to rebuild or reinstall the affected ports manually, since the new base version can't fix the metadata for ports that have already been installed.

comment:15 in reply to:  14 Changed 6 years ago by EJFielding (Eric Fielding)

You were right, "revupgrademode" was set to "report" but I have not changed my macports.conf file that I can remember and it has a modification date of January 2017. It was rebuilding before. Maybe the previous versions were not paying attention to that line.

comment:16 Changed 6 years ago by majoc-at-astro (majoc-at-astro)

Cc: majoc-at-astro added

comment:17 Changed 6 years ago by majoc-at-astro (majoc-at-astro)

For the record, still there for us on 10.13.4, built from the 2.5.1 MacPorts tarball:

### (229 of 264: min-test-set.sh) port install hdf5 +cxx +gcc7 +fortran +openmpi (Mon Jun  4 10:54:01 BST 2018)
[snipissimo]
--->  Building hdf5
--->  Staging hdf5 into destroot
--->  Deactivating hdf5 @1.10.2_0+cxx+fortran+gcc7+hl+openmpi
--->  Cleaning hdf5
--->  Uninstalling hdf5 @1.10.2_0+cxx+fortran+gcc7+hl+openmpi
--->  Cleaning hdf5
--->  Computing dependencies for hdf5
--->  Installing hdf5 @1.10.2_0+cxx+fortran+gcc7+hl+openmpi
--->  Activating hdf5 @1.10.2_0+cxx+fortran+gcc7+hl+openmpi
--->  Cleaning hdf5
--->  Scanning binaries for linking errors
--->  No broken files found.
Error: Port hdf5 is still broken after rebuilding it more than 3 times.

comment:18 Changed 6 years ago by jmroot (Joshua Root)

OK, so hdf5 at least still needs to be fixed. With those variants it's building with mpicxx-openmpi-gcc7. The mpi portgroup is probably where configure.cxx_stdlib needs to be set appropriately.

comment:19 in reply to:  18 Changed 6 years ago by EJFielding (Eric Fielding)

My py27-scipy and hdf5 ports were rebuilt successfully after I changed my macports.conf. Thanks!

I have "hdf5 @1.10.2_0+cxx+gcc7+hl" so I am not using openmpi in my hdf5 installation.

comment:20 Changed 6 years ago by jmroot (Joshua Root)

Resolution: fixed
Status: newclosed

I'll close this ticket then. I've opened a more specific one for mpi: #56608

Note: See TracTickets for help on using tickets.