Opened 10 months ago

Closed 8 months ago

#56521 closed update (fixed)

gcc8 @8-20170604_2: update to 8.1

Reported by: iqgrande Owned by: Chris Jones <jonesc@…>
Priority: Normal Milestone:
Component: ports Version: 2.4.4
Keywords: Cc: ryandesign (Ryan Schmidt), MarcusCalhoun-Lopez (Marcus Calhoun-Lopez), cjones051073 (Chris Jones), mopihopi, jeremyhu (Jeremy Huddleston Sequoia), vit9696, cooljeanius (Eric Gallager)
Port: gcc8

Description

Greetings:

GNU released GCC-8.1 on 2018-04-25. Could this port be updated to support this new version? Thank you for your help with this.

Kind regards, Anthony

Change History (25)

comment:1 Changed 10 months ago by ryandesign (Ryan Schmidt)

Cc: ryandesign added

We don't know how. Versions of gcc newer than 8-20170604 do not build for us and the developers do not respond to inquiries about the problem. Homebrew has managed to update gcc to 8.1; I don't know how they accomplished that given the problems we experience.

comment:2 Changed 10 months ago by kencu (Ken)

the only thing I can see in the homebrew formula that I don't think we're doing is this

make_args << "BOOT_LDFLAGS=-Wl,-headerpad_max_install_names"

and this:

    # GCC will suffer build errors if forced to use a particular linker.
    ENV.delete "LD"
Last edited 10 months ago by kencu (Ken) (previous) (diff)

comment:3 Changed 10 months ago by kencu (Ken)

the equivalent of the ENV.delete "LD" command on 10.13 is probably to install ld64 +ld64_xcode as we've seen a number of problems trying to use the older ld64 in MacPorts on 10.13 / Xcode 9.3. Or you could uninstall ld64, which would accomplish the same end, using the Xcode linker. And there are other ways of forcing that linker to be used, to be sure.

The BOOT_LDFLAGS looks like it could go into the configure.env and build.env setup.

So I have those chugging away now, on the gcc 8.1.0 release, and we'll see how far it gets...

comment:4 Changed 10 months ago by kencu (Ken)

and --- no. Same error. Although I don't see the BOOT_LDFLAGS mod on the build line:

/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_gcc8/libgcc-devel/work/build/./prev-gcc/xg++ -B/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_gcc8/libgcc-devel/work/build/./prev-gcc/ -B/opt/local/x86_64-apple-darwin17/bin/ -nostdinc++ -B/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_gcc8/libgcc-devel/work/build/prev-x86_64-apple-darwin17/libstdc++-v3/src/.libs -B/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_gcc8/libgcc-devel/work/build/prev-x86_64-apple-darwin17/libstdc++-v3/libsupc++/.libs  -isystem /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_gcc8/libgcc-devel/work/build/prev-x86_64-apple-darwin17/libstdc++-v3/include/x86_64-apple-darwin17  -isystem /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_gcc8/libgcc-devel/work/build/prev-x86_64-apple-darwin17/libstdc++-v3/include  -isystem /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_gcc8/libgcc-devel/work/gcc-8.1.0/libstdc++-v3/libsupc++ -L/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_gcc8/libgcc-devel/work/build/prev-x86_64-apple-darwin17/libstdc++-v3/src/.libs -L/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_gcc8/libgcc-devel/work/build/prev-x86_64-apple-darwin17/libstdc++-v3/libsupc++/.libs   -g -O2   -gtoggle -DIN_GCC     -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings   -DHAVE_CONFIG_H -DGENERATOR_FILE -fno-PIE -static-libstdc++ -static-libgcc -Wl,-no_pie  -o build/gengenrtl \
	    build/gengenrtl.o build/errors.o .././libiberty/libiberty.a
0  0x1050d72c0  __assert_rtn + 129
1  0x1050eaa99  mach_o::relocatable::Parser<x86_64>::parse(mach_o::relocatable::ParserOptions const&) + 3027
2  0x1050e2590  mach_o::relocatable::Parser<x86_64>::parse(unsigned char const*, unsigned long long, char const*, long, ld::File::Ordinal, mach_o::relocatable::ParserOptions const&) + 282
3  0x105127f01  ld::tool::InputFiles::makeFile(Options::FileInfo const&, bool) + 1207
4  0x10512ac8f  ld::tool::InputFiles::parseWorkerThread() + 535
5  0x7fff68164661  _pthread_body + 340
6  0x7fff6816450d  _pthread_body + 0
A linker snapshot was created at:
	/tmp/gengenrtl-2018-04-23-091325.ld-snapshot
ld: Assertion failed: (cfiStartsArray[i] != cfiStartsArray[i-1]), function parse, file /Library/Caches/com.apple.xbs/Sources/ld64/ld64-351.8/src/ld/parsers/macho_relocatable_file.cpp, line 1906.

comment:5 Changed 10 months ago by MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)

Cc: MarcusCalhoun-Lopez added

comment:6 Changed 10 months ago by kencu (Ken)

I tried it without -lto, I tried it with the -tls bit removed, I tried it with

use_parallel_build  no

I tried adding

-Wl,-headerpad_max_install_names

directly to the link line that fails.

I monkeyed with the linker, deleted all this stuff from the build

configure.env-append \
                    AR_FOR_TARGET=${prefix}/bin/ar \
                    AS_FOR_TARGET=${prefix}/bin/as \
                    LD_FOR_TARGET=${prefix}/bin/ld \
                    NM_FOR_TARGET=${prefix}/bin/nm \
                    OBJDUMP_FOR_TARGET=${prefix}/bin/objdump \
                    RANLIB_FOR_TARGET=${prefix}/bin/ranlib \
                    STRIP_FOR_TARGET=${prefix}/bin/strip \
                    OTOOL=${prefix}/bin/otool \
                    OTOOL64=${prefix}/bin/otool

all failed. I still get the same error, same place.

I don't know how the the homebrew build succeeds at present -- Next thing is to maybe get somebody to just build it outside of MacPorts, on it's own, perhaps.

comment:7 Changed 10 months ago by MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)

libgcc 8.1 built for me on macOS 10.13 with the following modification

configure.args-replace \                                                                                                                                                                                 
                    --with-as=${prefix}/bin/as \                                                                                                                                                         
                    --with-as=/usr/bin/as  

This would explain why the homebrew packages builds.
Perhaps this information would help move the upstream bug report along.

comment:8 Changed 10 months ago by kencu (Ken)

The assembler ! what the heck... it sure looked like a linker issue. Good work.

IIRC, /opt/local/bin/as would use /opt/local/bin/clang as the assembler... still not sure what is exactly going on to cause the error, but we have a good clue now...

comment:9 Changed 10 months ago by cjones051073 (Chris Jones)

Cc: cjones051073 added

comment:10 Changed 10 months ago by mopihopi

Cc: mopihopi added

comment:11 in reply to:  7 Changed 10 months ago by ryandesign (Ryan Schmidt)

Cc: jeremyhu added

Replying to MarcusCalhoun-Lopez:

libgcc 8.1 built for me on macOS 10.13 with the following modification

configure.args-replace \                                                                                                                                                                                 
                    --with-as=${prefix}/bin/as \                                                                                                                                                         
                    --with-as=/usr/bin/as  

Thanks Marcus, I can confirm that works for me too with Xcode 9.2 on macOS Sierra.

So I suppose the problem is that we were using as from cctools, which is version 895, which corresponds to Xcode 8.1, which is perhaps too old to do the right thing in this case.

I usually have the ld64 port installed with the +ld64_xcode variant (which uses the ld installed by Xcode), but I also tried with the default installation (which uses the ld64-latest port which uses ld 274.2 which is from Xcode 8.2.1); using --with-as=${prefix}/bin/as, it fails with either ld version.

Jeremy added --with-as (and --with-ld and --with-ar) to all the gcc ports 6 years ago, though the commit message doesn't mention why. Jeremy, do you remember? What do you recommend—revert that? update cctools and/or ld64-latest? all of the above?

comment:12 Changed 10 months ago by kencu (Ken)

It sounds like we need a cctools +xcode that calls the SDK tools, and both that and ld64 +ld64_xcode should be defaults on 10.13, at least until we sort out where this is going.

Last edited 10 months ago by kencu (Ken) (previous) (diff)

comment:13 Changed 10 months ago by vit9696

I agree with the cctools variant, and in fact proposed it some while ago in a separate issue: https://trac.macports.org/ticket/55705#comment:11 Every time llvm updates one has to refresh cctools (and formerly ld64) port, which is entirely pointless and tedious in mosern macOS versions. Moreover, in fact it cause numerous problems if macOS SDK contains special incompatibilities like this one. I will be quite grateful to anyone who submits a patch adding xcode variant to cctools port.

comment:14 Changed 10 months ago by vit9696

Cc: vit9696 added

comment:15 Changed 10 months ago by ryandesign (Ryan Schmidt)

Let us wait until Jeremy confirms that that is the course of action he wants to take.

comment:16 Changed 10 months ago by kencu (Ken)

It looks like a great majority of them could be replaced by one wrapper script that uses xcrun with the name of the tool reinplaced into it, should we decide to do that...

$ xcrun -f as
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/as
$ xcrun -f strings
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/strings
$ xcrun -f lipo
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/lipo
$ xcrun -f libtool
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/libtool
$ xcrun -f ranlib
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib
$ xcrun -f strip
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/strip
$ xcrun -f ar
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ar
$ xcrun -f otool
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/otool
$ xcrun -f seg_hack
/opt/local/bin/seg_hack
$ xcrun -f nm
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/nm
$ xcrun -f nm-classic
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/nm-classic
$ xcrun -f segedit
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/segedit
$ xcrun -f size
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/size
$ 

comment:17 Changed 9 months ago by cooljeanius (Eric Gallager)

Cc: cooljeanius added

comment:18 Changed 8 months ago by cjones051073 (Chris Jones)

Just FYI, I've submitted

https://github.com/macports/macports-ports/pull/2253

Without going into details (mail my privately if you are interested and have signed the beta NDA) I needed it to test the current macOS 10.14 public beta.

Last edited 8 months ago by cjones051073 (Chris Jones) (previous) (diff)

comment:19 Changed 8 months ago by vit9696

Hi,

Thank you very much for finding time work on it. It really needed some attention.

However, I am not sure it is the right decision of making cctools hacks within gcc port itself. Even if that fixes gcc compatibility with cctools, I am not positive other ports do not share the same issue. Could you please consider making a cctools +xcode variant and making a dependency on it, as a cleaner solution?

Vit

comment:20 Changed 8 months ago by cjones051073 (Chris Jones)

I think you have mis read what my PR does...

comment:21 Changed 8 months ago by cjones051073 (Chris Jones)

I haven't touched gcc. That PR is indeed to update cctools to add an Xcode variant..

comment:22 Changed 8 months ago by vit9696

Oh, sorry, my bad. This was in the gcc issue, and the e-mail was titled '#56521: gcc8 @8-20170604_2: update to 8.1'. I assumed way too early it was just an update to the gcc. Yes, now I actually reviewed the patch, and it looks pretty good to me, except maybe a commented out 'hardcode link to command line tools version' part (should this be a xcode_cmd variant instead?)

comment:23 Changed 8 months ago by cjones051073 (Chris Jones)

Thanks for taking a look, but if you have comments on the PR please post them there instead ;)

comment:24 Changed 8 months ago by cjones051073 (Chris Jones)

I just submitted

https://github.com/macports/macports-ports/pull/2296

which, as far as currently is possible (given the cctools limitations on Xcode < 9 systems), enables gcc8 (8.2.0) and gcc9 ports.

Please, take a good look at the PR and comment there.

comment:25 Changed 8 months ago by Chris Jones <jonesc@…>

Owner: set to Chris Jones <jonesc@…>
Resolution: fixed
Status: newclosed

In 37619a17caf48f80aafda18e5c46a6dcf68c9e32/macports-ports (master):

Updates to the various gcc<X> and libgcc<X> ports to update gcc8 to 8.2 stable release
and to add new gcc9 port based on a current beta snapshot. libgcc-devel consequently
updated to now be based of the same gcc9 snapshsot.

libgcc: Updated to be a standalone port, that picks the correct gcc primary runtime.
gcc8: Update to gcc 8.2.0
libgcc8: New port providing gcc 8.2.0 runtime
libgcc7: New port based gcc 7.3.0. Contains older API library versions updated in libgcc.
gcc7: Update to depend on libgcc7.
libgcc-devel: Update to gcc snapshot 9-20180722.
gcc9: New port based on gcc snapshot 9-20180722.

compilers-1.0.tcl : Updated to adapt to the new libgcc runtims as above
languages-1.0.tcl and to add gcc8 as a compiler option.

Closes: #56521

Note: See TracTickets for help on using tickets.