Opened 6 years ago
Closed 6 years 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 Carsten 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 6 years ago by ryandesign (Ryan Carsten Schmidt)
Cc: | ryandesign added |
---|
comment:2 Changed 6 years 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"
comment:3 Changed 6 years 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 6 years 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 6 years ago by MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)
Cc: | MarcusCalhoun-Lopez added |
---|
comment:6 Changed 6 years 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 follow-up: 11 Changed 6 years 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 6 years 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 6 years ago by cjones051073 (Chris Jones)
Cc: | cjones051073 added |
---|
comment:10 Changed 6 years ago by mopihopi
Cc: | mopihopi added |
---|
comment:11 Changed 6 years ago by ryandesign (Ryan Carsten Schmidt)
Cc: | jeremyhu added |
---|
Replying to MarcusCalhoun-Lopez:
libgcc
8.1 built for me on macOS 10.13 with the following modificationconfigure.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 6 years ago by kencu (Ken)
It sounds like we need a cctools +Xcode
that calls the SDK tools, and both that and ld64 +Xcode
should be defaults on 10.13, at least until we sort out where this is going.
comment:13 Changed 6 years 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 6 years ago by vit9696
Cc: | vit9696 added |
---|
comment:15 Changed 6 years ago by ryandesign (Ryan Carsten Schmidt)
Let us wait until Jeremy confirms that that is the course of action he wants to take.
comment:16 Changed 6 years 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 6 years ago by cooljeanius (Eric Gallager)
Cc: | cooljeanius added |
---|
comment:18 Changed 6 years 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.
comment:19 Changed 6 years 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 6 years ago by cjones051073 (Chris Jones)
I think you have mis read what my PR does...
comment:21 Changed 6 years 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 6 years 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 6 years 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 6 years 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 6 years ago by Chris Jones <jonesc@…>
Owner: | set to Chris Jones <jonesc@…> |
---|---|
Resolution: | → fixed |
Status: | new → closed |
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.