#56326 closed defect (fixed)
rev-upgrade considers gcc as broken due to libstdc++
Reported by: | raimue (Rainer Müller) | Owned by: | jmroot (Joshua Root) |
---|---|---|---|
Priority: | Normal | Milestone: | MacPorts 2.5.0 |
Component: | base | Version: | 2.4.99 |
Keywords: | Cc: | jmroot (Joshua Root), iEFdev | |
Port: |
Description
... ---> Found 1 broken file, matching files to ports gcc7 is using libstdc++ (this installation is configured to use libc++) gcc6 is using libstdc++ (this installation is configured to use libc++) ---> Found 3 broken ports, determining rebuild order DEBUG: Broken: pgAdmin3 DEBUG: Broken: gcc7 DEBUG: Broken: gcc6 DEBUG: Processing port pgAdmin3 @0:1.22.2_0 +postgresql95 DEBUG: Processing port gcc7 @2:7.3.0_0 DEBUG: Processing port gcc6 @2:6.4.0_0 ---> Rebuilding in order pgAdmin3 @1.22.2 +postgresql95 gcc7 @7.3.0 gcc6 @6.4.0 ...
I was unable to find out why it thinks gcc6 and gcc7 are broken. I installed both gcc6 and gcc7 from the archives from packages.macports.org. Even stranger, if I deactive pgAdmin3, no broken files will be found and then, gcc6 and gcc7 are also no longer considered broken.
Is this a problem with the gcc ports or with rev-upgrade reporting a false-positive? Why does it only appear when rev-upgrade finds at least one other broken port?
pgAdmin3 apparently was not rev-bumped for the readline @7.0 update (looks like it copied the psql binary into the port), so this is a separate problem that needs to be dealt with. However, gcc6 and gcc7 should not be involved in this at all.
I am attaching the full debug output.
Attachments (1)
Change History (10)
Changed 7 years ago by raimue (Rainer Müller)
Attachment: | rev-upgrade-gcc.log added |
---|
comment:1 Changed 7 years ago by neverpanic (Clemens Lang)
comment:2 Changed 7 years ago by jmroot (Joshua Root)
Hmm. I can't think of a better way to work around this than having a list of ports to ignore when rev-upgrade adds this information.
comment:3 Changed 7 years ago by raimue (Rainer Müller)
comment:4 Changed 7 years ago by raimue (Rainer Müller)
I am fine if this would be fixed once we release MacPorts 2.5.0. We just have to remember to rev-bump the gcc ports then.
To ease the transition, maybe we could have a port-upgrade script that sets cxx_stdlib
and cxx_stdlib_overridden
for well-known ports?
comment:5 Changed 7 years ago by neverpanic (Clemens Lang)
Milestone: | → MacPorts 2.5.0 |
---|
comment:6 Changed 7 years ago by jmroot (Joshua Root)
Owner: | set to jmroot |
---|---|
Resolution: | → fixed |
Status: | new → closed |
comment:7 Changed 7 years ago by jmroot (Joshua Root)
If you have gcc or one of the other listed ports installed, please test that this works.
comment:8 Changed 7 years ago by raimue (Rainer Müller)
Thanks, that seems to work as intended. I reset cxx_stdlib = NULL
for gcc6 and gcc7, then upgraded base to current master. Now sudo port rev-upgrade
no longer considers the ports as broken.
comment:9 Changed 6 years ago by iEFdev
Cc: | iEFdev added |
---|
pgAdmin3 is considered broken because of
It seems it should have been revbumped for the readline update.
gcc6 and gcc7 seem to be considered broken because the discovered value for the c++ stdlib used by the port does not match your global configuration (which defaults to libc++). Of course that's a false positive for these ports. There is an override to deal with this, but the override requires information from the Portfile to be set. This only works when installing the port freshly, but does not work when rev-upgrade initially determines the c++ stdlib usage of a port, which is why this code path assumes a false value for cxx_stdlib_overridden, which then causes this problem.
This should not occur when compiling GCC from source, and it should also not occur when installing from a prebuilt package, but only if the prebuilt package was compiled with a version of MacPorts that supports setting this flag (which of course our buildbots are currently not running yet).
This is not ideal. Maybe jmr has an idea how to solve this?