Bug 237688 - 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
Summary: lang/gcc8 fails to build: /usr/local/bin/ld: /wrkdirs/usr/ports/lang/gcc8/wor...
Status: Closed Not A Bug
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: amd64 Any
: --- Affects Only Me
Assignee: freebsd-toolchain (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-05-01 14:36 UTC by tech-lists
Modified: 2019-06-08 15:55 UTC (History)
4 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description tech-lists 2019-05-01 14:36:17 UTC
Hi,

context: amd6412-stable r346957
poudriere-devel ver. 3.3.99.20190311
ports r500582

error:

[00:08:15] /wrkdirs/usr/ports/lang/gcc8/work/.build/./gcc/xgcc -B/wrkdirs/usr/ports/lang/gcc8/work/.build/./gcc/ -B/usr/local/x86_64-portbld-freebsd12.0/bin/ -B/usr/local/x86_64-portbld-freebsd12.0/lib/ -isystem /usr/local/x86_64-portbld-freebsd12.0/include -isystem /usr/local/x86_64-portbld-freebsd12.0/sys-include    -O2  -g -O2 -pipe -march=haswell  -DLIBICONV_PLUG -fno-strict-aliasing  -DIN_GCC    -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-format -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition  -isystem ./include   -fpic -pthread -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector  -shared -nodefaultlibs -Wl,--soname=libgcc_s.so.1 -Wl,--version-script=libgcc.map -o 32/libgcc_s.so.1.tmp -g -O2 -pipe -march=haswell -DLIBICONV_PLUG -fno-strict-aliasing -m32 -B./ _muldi3_s.o _negdi2_s.o _lshrdi3_s.o _ashldi3_s.o _ashrdi3_s.o _cmpdi2_s.o _ucmpdi2_s.o _clear_cache_s.o _trampoline_s.o __main_s.o _absvsi2_s.o _absvdi2_s.o _addvsi3_s.o _addvdi3_s.o _subvsi3_s.o _subvdi3_s.o _mulvsi3_s.o _mulvdi3_s.o _negvsi2_s.o _negvdi2_s.o _ctors_s.o _ffssi2_s.o _ffsdi2_s.o _clz_s.o _clzsi2_s.o _clzdi2_s.o _ctzsi2_s.o _ctzdi2_s.o _popcount_tab_s.o _popcountsi2_s.o _popcountdi2_s.o _paritysi2_s.o _paritydi2_s.o _powisf2_s.o _powidf2_s.o _powixf2_s.o _powitf2_s.o _mulhc3_s.o _mulsc3_s.o _muldc3_s.o _mulxc3_s.o _multc3_s.o _divhc3_s.o _divsc3_s.o _divdc3_s.o _divxc3_s.o _divtc3_s.o _bswapsi2_s.o _bswapdi2_s.o _clrsbsi2_s.o _clrsbdi2_s.o _fixunssfsi_s.o _fixunsdfsi_s.o _fixunsxfsi_s.o _fixsfdi_s.o _fixdfdi_s.o _fixxfdi_s.o _fixunssfdi_s.o _fixunsdfdi_s.o _fixunsxfdi_s.o _floatdisf_s.o _floatdidf_s.o _floatdixf_s.o _floatundisf_s.o _floatundidf_s.o _floatundixf_s.o _divdi3_s.o _moddi3_s.o _divmoddi4_s.o _udivdi3_s.o _umoddi3_s.o _udivmoddi4_s.o _udiv_w_sdiv_s.o cpuinfo_s.o tf-signs_s.o sfp-exceptions_s.o addtf3_s.o divtf3_s.o eqtf2_s.o getf2_s.o letf2_s.o multf3_s.o negtf2_s.o subtf3_s.o unordtf2_s.o fixtfsi_s.o fixunstfsi_s.o floatsitf_s.o floatunsitf_s.o fixtfdi_s.o fixunstfdi_s.o floatditf_s.o floatunditf_s.o extendsftf2_s.o extenddftf2_s.o extendxftf2_s.o trunctfsf2_s.o trunctfdf2_s.o trunctfxf2_s.o enable-execute-stack_s.o unwind-dw2_s.o unwind-dw2-fde-dip_s.o unwind-sjlj_s.o unwind-c_s.o emutls_s.o libgcc.a -lc && rm -f 32/libgcc_s.so && if [ -f 32/libgcc_s.so.1 ]; then mv -f 32/libgcc_s.so.1 32/libgcc_s.so.1.backup; else true; fi && mv 32/libgcc_s.so.1.tmp 32/libgcc_s.so.1 && ln -s libgcc_s.so.1 32/libgcc_s.so
[00:08:16] /usr/local/bin/ld: /wrkdirs/usr/ports/lang/gcc8/work/.build/./gcc/liblto_plugin.so: error loading plugin: Service unavailable
[00:08:16] collect2: error: ld returned 1 exit status
[00:08:16] gmake[6]: *** [Makefile:985: libgcc_s.so] Error 1
[00:08:16] gmake[6]: Leaving directory '/wrkdirs/usr/ports/lang/gcc8/work/.build/x86_64-portbld-freebsd12.0/32/libgcc'
[00:08:16] gmake[5]: *** [Makefile:1201: multi-do] Error 1
[00:08:16] gmake[5]: Leaving directory '/wrkdirs/usr/ports/lang/gcc8/work/.build/x86_64-portbld-freebsd12.0/libgcc'
[00:08:16] gmake[4]: *** [Makefile:125: all-multi] Error 2
[00:08:16] gmake[4]: Leaving directory '/wrkdirs/usr/ports/lang/gcc8/work/.build/x86_64-portbld-freebsd12.0/libgcc'
[00:08:16] gmake[3]: *** [Makefile:17211: all-stage1-target-libgcc] Error 2
[00:08:16] gmake[3]: Leaving directory '/wrkdirs/usr/ports/lang/gcc8/work/.build'
[00:08:16] gmake[2]: *** [Makefile:22433: stage1-bubble] Error 2
[00:08:16] gmake[2]: Leaving directory '/wrkdirs/usr/ports/lang/gcc8/work/.build'
[00:08:16] gmake[1]: *** [Makefile:22765: bootstrap-lean] Error 2
[00:08:16] gmake[1]: Leaving directory '/wrkdirs/usr/ports/lang/gcc8/work/.build'
[00:08:16] ===> Compilation failed unexpectedly.

Full error at https://cloud.zyxst.net/~john/FreeBSD/ports/buildfailures/gcc8-8.3.0_2.log **warning log file is 42MB **
Comment 1 tech-lists 2019-05-07 23:56:13 UTC
also tried testport with the three make config options available and it fails in the same place even with them all turned off.
Comment 2 Gerald Pfeifer freebsd_committer freebsd_triage 2019-05-08 05:16:14 UTC
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?
Comment 3 Mark Millard 2019-05-08 06:02:44 UTC
(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/ )
Comment 4 Dimitry Andric freebsd_committer freebsd_triage 2019-05-08 06:10:06 UTC
(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.
Comment 5 Gerald Pfeifer freebsd_committer freebsd_triage 2019-05-08 07:18:32 UTC
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?
Comment 6 tech-lists 2019-05-08 11:41:13 UTC
as far as I'm aware, binutils wasn't compiled with non-default options. I'll check.
Comment 7 tech-lists 2019-05-08 11:53:16 UTC
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
Comment 8 Dimitry Andric freebsd_committer freebsd_triage 2019-05-08 17:21:27 UTC
(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?
Comment 9 Mark Millard 2019-05-08 20:29:59 UTC
(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.
Comment 10 tech-lists 2019-05-08 21:38:03 UTC
(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.
Comment 11 tech-lists 2019-05-08 21:38:57 UTC
(In reply to tech-lists from comment #7)

confirm it now builds, thanks everyone
Comment 12 tech-lists 2019-05-09 12:53:36 UTC
(In reply to Gerald Pfeifer from comment #5)
should I close this or would you rather it be left open as per your comment?
Comment 13 Gerald Pfeifer freebsd_committer freebsd_triage 2019-06-08 15:55:14 UTC
(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