Bug 236055 - lang/gcc8 Linker command failed due to signal
Summary: lang/gcc8 Linker command failed due to signal
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 mailing list
Depends on:
Reported: 2019-02-26 14:27 UTC by drhowarddrfine
Modified: 2019-02-28 02:31 UTC (History)
3 users (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description drhowarddrfine 2019-02-26 14:27:02 UTC

c++ -std=gnu++98 -fno-PIE -c  -DIN_GCC_FRONTEND -g -DIN_GCC    -fno-strict-aliasing -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-format -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common  -DHAVE_CONFIG_H -I. -I. -I/usr/ports/lang/gcc8/work/gcc-8.3.0/gcc -I/usr/ports/lang/gcc8/work/gcc-8.3.0/gcc/. -I/usr/ports/lang/gcc8/work/gcc-8.3.0/gcc/../include -I/usr/ports/lang/gcc8/work/gcc-8.3.0/gcc/../libcpp/include -I/usr/local/include  -I/usr/ports/lang/gcc8/work/gcc-8.3.0/gcc/../libdecnumber -I/usr/ports/lang/gcc8/work/gcc-8.3.0/gcc/../libdecnumber/dpd -I../libdecnumber -I/usr/ports/lang/gcc8/work/gcc-8.3.0/gcc/../libbacktrace  -DLIBICONV_PLUG -o cc1-checksum.o -MT cc1-checksum.o -MMD -MP -MF ./.deps/cc1-checksum.TPo cc1-checksum.c
c++: warning: treating 'c' input as 'c++' when in C++ mode, this behavior is deprecated [-Wdeprecated]
c++ -std=gnu++98 -no-pie   -g -DIN_GCC    -fno-strict-aliasing -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-format -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common  -DHAVE_CONFIG_H  -o cc1 c/c-lang.o c-family/stub-objc.o attribs.o c/c-errors.o c/c-decl.o c/c-typeck.o c/c-convert.o c/c-aux-info.o c/c-objc-common.o c/c-parser.o c/c-fold.o c/gimple-parser.o c-family/c-common.o c-family/c-cppbuiltin.o c-family/c-dump.o c-family/c-format.o c-family/c-gimplify.o c-family/c-indentation.o c-family/c-lex.o c-family/c-omp.o c-family/c-opts.o c-family/c-pch.o c-family/c-ppoutput.o c-family/c-pragma.o c-family/c-pretty-print.o c-family/c-semantics.o c-family/c-ada-spec.o c-family/c-ubsan.o c-family/known-headers.o c-family/c-attribs.o c-family/c-warn.o c-family/c-spellcheck.o i386-c.o default-c.o \
  cc1-checksum.o libbackend.a main.o libcommon-target.a libcommon.a ../libcpp/libcpp.a ../libdecnumber/libdecnumber.a libcommon.a ../libcpp/libcpp.a   ../libbacktrace/.libs/libbacktrace.a ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a   -L/usr/local/lib -lmpc -lmpfr -lgmp -rdynamic  -lz
c++: warning: argument unused during compilation: '-nopie' [-Wunused-command-line-argument]
c++: error: unable to execute command: Killed
c++: error: linker command failed due to signal (use -v to see invocation)
gmake[5]: *** [/usr/ports/lang/gcc8/work/gcc-8.3.0/gcc/c/Make-lang.in:85: cc1] Error 254
gmake[5]: Leaving directory '/usr/ports/lang/gcc8/work/.build/gcc'
gmake[4]: *** [Makefile:4611: all-stage1-gcc] Error 2
gmake[4]: Leaving directory '/usr/ports/lang/gcc8/work/.build'
gmake[3]: *** [Makefile:22433: stage1-bubble] Error 2
gmake[3]: Leaving directory '/usr/ports/lang/gcc8/work/.build'
gmake[2]: *** [Makefile:22765: bootstrap-lean] Error 2
gmake[2]: Leaving directory '/usr/ports/lang/gcc8/work/.build'
===> Compilation failed unexpectedly.
Try to set MAKE_JOBS_UNSAFE=yes and rebuild before reporting the failure to
the maintainer.
*** Error code 1

make[1]: stopped in /usr/ports/lang/gcc8
*** Error code 1
Comment 1 Gerald Pfeifer freebsd_committer 2019-02-26 20:37:26 UTC
There's not much I can do with this report (except to note that it does
appear to work for others).  

Is this reproducible?  That is, what happens if you try to build this
multiple times?  Does it always fail?  And always at the same place?

Are all dependencies fully up-to-date?

Can you rule out a hardware problem (memory,...)?

Any other ideas, toolchain@ ?
Comment 2 Dimitry Andric freebsd_committer 2019-02-26 20:46:25 UTC
(In reply to Gerald Pfeifer from comment #1)
> There's not much I can do with this report (except to note that it does
> appear to work for others).
> Any other ideas, toolchain@ ?

At first sight, it looks like the linker ran out of memory.  @drhowarddrfine, can you please check your dmesg for messages like "out of swap space"?
Comment 3 drhowarddrfine 2019-02-27 04:50:03 UTC
(In reply to Dimitry Andric from comment #2)
Well, yes, as a matter of fact, I was working on my workstation and hadn't checked my email only to find that I am getting messages saying I ran out of swap space. This is a small server so I'm betting that's the issue. 

Sorry to bother.
Comment 4 Ed Maste freebsd_committer 2019-02-27 20:57:40 UTC
I wonder if we should add a note to the 'failed unexpectedly' message suggesting the user check for OOM issues etc.
Comment 5 Mark Millard 2019-02-28 02:31:13 UTC
(In reply to Ed Maste from comment #4)

It would also help if the dmesg/console messages avoided
incorrectly referencing "out of swap" when such need not
be involved.

Details follow, describing the current context.

If the person with the problem see any of the:

swap_pager_getswapspace(number): failed

message they really were out of swap. But if
they only see:

kernel: pid ... (...), uid ..., was killed: out of swap space

they likely had swap available, the issue not
really being swap space.

The 2nd type of message can happen when there is
plenty of swap but processes that stay runnable are
preventing having sufficient free RAM after some
number of tries by FreeBSD: runnable processes are
not (fully) swapped-out by FreeBSD, only paged.

In my view the "was killed: out of swap space" should
text be adjusted.

Other notes:

There is a tunable that can increase the number
of tries at freeing RAM before "was killed: out
of swap space" happens. This is used on low end
armv7's and aarch64's and such to allow buildworld
and the like to complete with -j4, for example.

vm.pageout_oom_seq has a default of 12 (last I
checked). Figures like 120 and 1024 have been
used on those low end armv7 and aarch64 examples.
(pi2 V1.1 and rpi3 are examples: just 1 GiByte
of RAM. Of course sufficient swap space is also
required for this kind of context.)

For lld based links, LDFLAGS.lld+= -Wl,--no-threads
can also help avoid memory use by avoiding having
ncpu+2 threads in use in each active lld.

How-to-build-software documentation should probably
cover this subject.