[Bug target/31798] lib1funcs.asm:1000: undefined reference to `raise'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31798 Eric Gallager changed: What|Removed |Added Status|RESOLVED|REOPENED Last reconfirmed||2019-06-14 CC||egallager at gcc dot gnu.org Resolution|WORKSFORME |--- Ever confirmed|0 |1 --- Comment #5 from Eric Gallager --- (In reply to Rich Felker from comment #2) > This does seem to be real, so please reopen it. (In reply to Dima Krasner from comment #3) > Please re-open this bug. OK.
[Bug target/31798] lib1funcs.asm:1000: undefined reference to `raise'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31798
David Grayson changed:
What|Removed |Added
CC||davidegrayson at gmail dot com
--- Comment #5 from David Grayson ---
This bug is still present, at least in GCC 6.3.0. I have not tried a newer
version.
== Workarounds ==
For any GCC users getting an undefined reference error for "raise", you should
try providing the "-static" option to GCC when you link your program.
Alternatively, if you are compiling GCC yourself, you should find the
definition of LINK_GCC_C_SEQUENCE_SPEC in GCC's source code and change it to be
this:
--start-group %G %L --end-group
In my case, I am building a GCC 6.3.0 cross-compiler to target musl Linux, and
the definition I had to change was in "gcc/config/gnu-user.h".
You can see my build scripts here if you are interested in using GCC to build
static programs targeting Windows and Linux:
https://github.com/DavidEGrayson/nixcrpkgs
== Comments ==
Thank you for diagnosing this correctly, Rich Felker. Also, your
musl-cross-make project was useful to me.
The core problem here is that LINK_GCC_C_SEQUENCE_SPEC is sometimes defined
like this:
%{static:--start-group} %G %L %{static:--end-group}%{!static:%G}
You can run "gcc -dumpspecs" and look for "link_gcc_c_sequence" to see how it
was defined in your version of GCC. The %G basically stands for "-lgcc" and
the %L basically stands for "-lc".
The problem with that line is that it is confusing two different concepts:
A) The program is being linked with "-static".
B) The libc and GCC libraries used by the program are static.
A implies B, but B does not imply A. I am using GCC to build static
applications so I don't have a shared version of libc or the GCC libraries, and
I want my programs to compile and link correctly even if the "-static" argument
is not supplied.
Why was this marked as "WORKSFORME", which is defined in by this bug tracker to
be "All attempts at reproducing this bug were futile, and ..."? From the
conversation here it sure seems like there was no attempt to understand the
configuration of the original poster's GCC and system libraries and actually
reproduce the issue. If anyone wants help reproducing this issue, I can easily
show you how to do it using my build scripts from the nixcrpkgs project. One
of the advantages of Nix is that it's great for expressing how to build
software and compositions of software in a reliable and predictable way, so if
you have a Linux system you can just run a few commands and get the exact same
error I was getting when I tried to build a "hello world" program for the
Raspberry Pi.
[Bug target/31798] lib1funcs.asm:1000: undefined reference to `raise'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31798 andyg1001 at hotmail dot co.uk changed: What|Removed |Added CC||andyg1001 at hotmail dot co.uk --- Comment #4 from andyg1001 at hotmail dot co.uk --- Did this bug ever get resolved satisfactorily? For now, the only solution, as suggested by Rich Felker, is to have for example a dummy division instruction somewhere in the code that's being compiled. I'm using gcc 4.8.5 with musl-libc 1.1.12.
[Bug target/31798] lib1funcs.asm:1000: undefined reference to `raise'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31798 Dima Krasner dima at dimakrasner dot com changed: What|Removed |Added CC||dima at dimakrasner dot com --- Comment #3 from Dima Krasner dima at dimakrasner dot com --- Please re-open this bug. I'm affected by it with GCC 4.8.3, when I build static ARMv7 binaries against musl 1.0.4.
[Bug target/31798] lib1funcs.asm:1000: undefined reference to `raise'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31798 Rich Felker bugdal at aerifal dot cx changed: What|Removed |Added CC||bugdal at aerifal dot cx --- Comment #2 from Rich Felker bugdal at aerifal dot cx --- This does seem to be real, so please reopen it. The problem is that the final command line to the linker looks like: ... $(objs) -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed $(endfiles) Assuming the main program itself does not do any division or call raise, the first -lgcc does not pull in __div0, and the -lc does not pull in raise. However, if any function from libc which does get pulled in performs division, then a reference to __div0 is generated, and the second -lgcc pulls in __div0, which contains a reference to raise. This reference is never resolved. It seems the intent is that link_gcc_c_sequence uses --start-group and --end-group to avoid this problem when -static is used. However, this does not cover the case where no libc.so exists at all, and libc.a is all that's available. I wonder why the --start-group logic is only used for static linking and not unconditionally, since it should be a no-op for shared libraries anyway. FYI, I have received new reports of this bug from musl users, one who wanted to have libc.so be used but who installed it in the wrong location causing libc.a to get used instead, but the rest were users doing purely static-linked systems with no shared libraries at all.
[Bug target/31798] lib1funcs.asm:1000: undefined reference to `raise'
--- Comment #1 from rearnsha at gcc dot gnu dot org 2007-05-29 13:22 --- The __div0 function is called by the division routines when an attempt to divide by zero is detected. On a linux system, it is expected that this will cause SIGFPE to be raise(3)d, so the default implementation of this call does precisely this. There's two ways you can avoid this problem when trying to build uboot (which isn't a linux application). 1) Provide your own implementation of __div0 that does the right thing for your system. 2) Use a different configuration of the compiler. Either way, this isn't a bug in the compiler. -- rearnsha at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31798
