[MacPorts] #54773: port:libgcc/port:gcc7: proposed modifications, efficiency + libc++ support

[MacPorts]

#54773: port:libgcc/port:gcc7: proposed modifications, efficiency + libc++ support
--------------------------+----------------------
  Reporter:  RJVB         |      Owner:
      Type:  enhancement  |     Status:  new
  Priority:  Normal       |  Milestone:
 Component:  ports        |    Version:
Resolution:               |   Keywords:  haspatch
      Port:  gcc7 libgcc  |
--------------------------+----------------------

Comment (by jeremyhu):

 Replying to [comment:3 RJVB]:
 > I don't understand your point 2, esp. not the point of incorrect dylib
 IDs. I'm not modifying those.

 Exactly,  that is the problem.  You need to modify them and install them
 into the common path.

 Instead, you're not modifying them and symlinking them from the common
 path.

 > Yes, the point of the +with_libgcc variant is to install gcc as one
 would normally do, and let port:libgcc install symlinks instead of actual
 library files, which point to the libraries installed by port:gcc7. That's
 enough to satisfy the dependencies of the binary builds provided by the
 build bots.

 And them when you go and install gcc8+with_libgcc and uninstall gcc7, all
 the ports that link against those runtime libraries are then broken.

 That is why you need to have the files in the common location and symlink
 them from the versioned paths.

 > > For the +libcxx changes... is g++ expected to be compatible with
 libc++?
 >
 > Why would it not be, provided you use the correct headerfiles? My
 changes basically implement the instructions given on
 http://libcxx.llvm.org/docs/UsingLibcxx.html#using-libc-with-gcc so there
 is some form of support for using libc++ with g++. In fact, I understand
 that libc++ aims to be a modern alternative to libstdc++, not something
 that is usable only with llvm.

 > I have asked on the GCC ML and it was confirmed that this change will
 also be considered for inclusion into gcc provided it doesn't hardcode the
 choice of runtime but adds a -stdlib option like clang has. I don't
 particularly mind trying to get that done properly before presenting the
 patch upstream (helping hands appreciated). But I'd really like to be able
 to argue that it has been tested by others before presenting it upstream.

 Well if that's the case, then I suppose that is fine.  However, older
 versions of gcc might not be able to support required features for newer
 libc++, so be careful.

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