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

MacPorts noreply at macports.org
Mon Sep 11 19:29:53 UTC 2017


#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:18 jeremyhu]:

 > gcc7 should really only get changes after they've landed in gcc8.  Just
 do your testing against the gcc7 port and then apply the diff to gcc8.
 They're basically identical.

 I was counting on the ports to be mostly similar, I also hope my changes
 can land at about the same time in both ports. Users interested in testing
 libc++ support should be able to do so with a release compiler.

 > How do you intend to handle conflicts between gcc7 and gcc8-provided
 libgcc in your variant scheme?

 There shouldn't be any more conflicts than there are currently. Certainly
 not between the gcc7-provided libgcc and the gcc8-provided libgcc-devel as
 those ports conflict.

 I have followed your suggestions about the install location for the
 runtime (libgcc) libraries. My `port:gcc7+with_libgcc` variant now also
 puts them into lib/libgcc, and `port:libgcc+stub` only puts a placeholder
 into that location. It took me some time to get changing the rpath in the
 libgcc_ext libraries right, but I found a way (`ex` to the rescue! :))
 Why doesn't install_name_tool support changing that kind of stub library
 anyway?

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


More information about the macports-tickets mailing list