#54198: upgrade: port:gcc7
Reporter: RJVB | Owner:
Type: update | Status: new
Priority: Normal | Milestone:
Component: ports | Version:
Keywords: haspatch | Port: gcc7
This ticket provides patches to upgrade port:gcc7 from a recent beta
version to the 7.1.0 release version. Tested on OS X 10.9.5 .
Gcc 7.1.0 comes with a new libgfortran; this ticket does not provide the
patch(es) required to adapt port:gcc6 (and earlier version?) to add a
port:libgcc6 (I'm curious why the libgcc ports handle ABI changes this way
while all other ports just expect dependents to revbump and rebuild?)
I've added 1 small patch which makes gcc c.s. invoke the cctools assembler
with the `-q` option. This option makes `as` invoke the clang integrated
assembler instead of running its own obsolete GNU-as based routines; the
option is supposedly the default but that is clearly not the case in
practice. It does indicate that the option must be safe to use; the effect
is that the GCC compilers will use an up-to-date assembler with support
for instruction sets unknown to Apple's GNU as fork.
I'm including a 2nd Portfile patch, to be applied to the upgraded Portfile
which I think should be incorporated at the same time as the upgrade. This
provides a PoC implementation of the variant I suggested to roll back the
standard runtime libraries into the main port, and turn port:libgcc into a
stub that exposes the runtime dylibs into $prefix/lib/libgcc. This cuts
install and upgrade times roughly in half for users who install from
source, which is all the more interesting to those who need the universal
variant. It requires no functionality that should be part of "Base", it
just inverts the symlinking logic.
Concretely, interested users can install port:gcc7 with the `+with_libgcc`
variant (name open for improvement). This simply removes the port's
dependency on port:libgcc and shunts the post-destroot code replacing the
dylibs concerned with symlinks.
Then, when port:libgcc is required or upgraded, the `with_libgcc` variant
is detected. That leads to the auto-activation of a `+stub` variant, which
adds a dependency on port:gcc7, drops all source-related phases and re-
define the destroot phase to create symlinks in $prefix/lib/libgcc that
point to the dylibs in $prefix/lib/gcc7.
(I considered using the same variant for both ports but failed to find a
term that makes sense for both).
RE: the with_libgcc and stub variants: a single `+single_build` variant
might be sufficiently unambiguous to work for both subports, and also
indicate that it is of little interest unless you're building the port
One remark: I did have a single build failure yesterday, a crash of the
cc1plus backend during (I think) the fore-last build phase. When I
repeated the `port build` command it completed just fine so it was
probably just a glitch, possibly due to memory pressure. (Or caused by the
fact I added `-march=native` to configure.optflags as a reflex.)