[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 RJVB):

 Replying to [comment:5 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.

 I see your point now. Fixing that shouldn't be too hard, just copy
 libgcc's post-destroot into gcc's (and just keep the headers in libgcc).

 Your suggestion to modify the build system to build only libgcc is nice,
 but I don't see that happening. I'd have a try if this were using cmake
 but not with the current monstrosity combining autotools with a 3-step
 bootstrap procedure.

 > 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.

 My first attempt at this was with gcc 6.3.0, which worked fine. I'm not
 planning on backporting it, but the code I'm patching is well preserved
 since several versions. I'll leave it to upstream to decide to which older
 versions this can be cherry-picked to when we get at that point.

 > And that's exactly my point. cctools cannot depend on the clang ports
 and thus cannot specify what version of clang is used because MacPorts
 does not support the type of dependency needed here.

 If I understand correctly, cctools invokes something that is installed by
 `port select`. That's yet another layer of complexity. What I don't get is
 why it doesn't simply invoke clang. That will cause it to catch
 ${prefix}/bin/clang if it exists, but use the system compiler/assembler
 otherwise, thus doing exactly what make, cmake and family do.

 Which frankly I think is preferable from a usability point of view. Being
 able to depend on a specific compiler version is nice for some things but
 most of the time it's just a PITA ...\\
 ...\\
 Cf. `port:libgcc` ;)

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