[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