Summary: | lang/gcc8 fails to build: /usr/local/bin/ld: /wrkdirs/usr/ports/lang/gcc8/work/.build/./gcc/liblto_plugin.so: error loading plugin: Service unavailable | ||
---|---|---|---|
Product: | Ports & Packages | Reporter: | tech-lists |
Component: | Individual Port(s) | Assignee: | freebsd-toolchain (Nobody) <toolchain> |
Status: | Closed Not A Bug | ||
Severity: | Affects Only Me | CC: | bapt, gerald, marklmi26-fbsd, svysh.fbsd |
Priority: | --- | ||
Version: | Latest | ||
Hardware: | amd64 | ||
OS: | Any |
Description
tech-lists
2019-05-01 14:36:17 UTC
also tried testport with the three make config options available and it fails in the same place even with them all turned off. I will admit I don't know what might be going on here. This is the only report like this from any user, and it's about the default GCC port in the Ports Collection, so it must be rather specific to your system/configuration. What non-default options do you have, for ports as well as the core system? (In reply to Gerald Pfeifer from comment #2) https://lists.freebsd.org/pipermail/freebsd-ports/2017-May/108816.html reports that having ld (from devel/binutils) built as a static executable produces such errors. Another place (forum) says: Make sure the STATIC option is off in devel/binutils and rebuild it. ( https://forums.freebsd.org/threads/poudriere-problem-with-lang-gcc7.65721/ ) (In reply to tech-lists from comment #0) ... > [00:08:16] /usr/local/bin/ld: > /wrkdirs/usr/ports/lang/gcc8/work/.build/./gcc/liblto_plugin.so: error > loading plugin: Service unavailable This is what happens when you link your binutils statically (e.g. the STATIC option in devel/binutils). A static ld cannot load any LTO plugin .so files: if you attempt to do so, you get this unhelpful "Service unavailable" error. So, it was a non-default setting after all. ;-) That said, is there a better way of reasonably handling this within our ports framework? Something like .if $(binutils built statically) IGNORE= GCC requires dynamically linked binutils .endif Or perhaps drop the STATIC option from devel/binutils? Is this an important one for users? as far as I'm aware, binutils wasn't compiled with non-default options. I'll check. yes, binutils had the static option enabled, the other two options were off. I have no idea what would have done that as it's not a thing I'd use directly. The make.conf for the jail looks like this: OPTIONS_SET+= OPTIMIZED_FLAGS OPTIMIZED_CFLAGS ICONV OPTIONS_UNSET+= IP6 CPUTYPE?=haswell USE_LOCALE=en_GB.UTF-8 running a build now with just NLS enabled for binutils (In reply to Gerald Pfeifer from comment #5) > So, it was a non-default setting after all. ;-) > > That said, is there a better way of reasonably handling this within our > ports framework? Something like > > .if $(binutils built statically) > IGNORE= GCC requires dynamically linked binutils > .endif Something like that, or somehow disable LTO plugins when building gcc, or at least warning about it. > Or perhaps drop the STATIC option from devel/binutils? Is this an > important one for users? I think this option mirrors what we have in the base system, where for apparently historical reasons, most toolchain components (cc, ld, etc) are built statically. Most likely, the idea was to be able to get yourself out of certain situations where the system is messed up, and then being able to rebuild it. It was added in ports r434650 by bdrewery, maybe he remembers what it was meant for? (In reply to Dimitry Andric from comment #8) There was a time when ld had to be linked statically for using the poudriere/qemu mix for aarch64 targeting that was based on using aarch64-binutils: cross builds. I have not checked if this is still true. But I've had to build ld statically in the past for this case. (In reply to Mark Millard from comment #9) Yes I think I may have built it statically in the past after following cross-compilation instructions, as this machine cross compiles arm stuff. Maybe it's not needed now with native cross-compile tools. (In reply to tech-lists from comment #7) confirm it now builds, thanks everyone (In reply to Gerald Pfeifer from comment #5) should I close this or would you rather it be left open as per your comment? (In reply to tech-lists from comment #12) > should I close this or would you rather it be left open as per your comment? Let's close this, and I'll ask on freebsd-ports@ and (one last time here) how to practically go about implementing .if $(binutils built statically) IGNORE= GCC requires dynamically linked binutils .endif |