Bug 5276 - linking fails with large C++ projects with -Wl,--relax
Summary: linking fails with large C++ projects with -Wl,--relax
Status: REOPENED
Alias: None
Product: binutils
Classification: Unclassified
Component: ld (show other bugs)
Version: 2.25
: P2 normal
Target Milestone: ---
Assignee: unassigned
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-11-06 14:57 UTC by Oliver Falk
Modified: 2020-07-02 04:23 UTC (History)
9 users (show)

See Also:
Host: alpha-redhat-linux
Target: alpha-redhat-linux
Build: alpha-redhat-linux
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Oliver Falk 2007-11-06 14:57:17 UTC
Last time I tried rebuilding firefox 2.0.0.8 rpm from Fedora on my Alpha it
failed with some relocation problems like this:

... relocation truncated to fit: GPREL16 against symbol ...

(Build log: http://buildsys.zero42.at/koji/getfile?taskID=53055&name=build.log)

I know this error very well, because I've seen it many times when using relaxed
binutils, especially when linking large c++ stuff.

So to prove this, I today tried to build firefox 2.0.0.9 again and a similar
problem occured. After the failed build I added -Wl,--no-relax to my LDFLAGS.
Well, you can expect what happened: It finished building. It - of course - took
longer to build, but worked...

Do you need any input? I'm willing to give ssh access to the build machine if
that helps!
Comment 1 H.J. Lu 2007-11-07 04:51:55 UTC
Can you try binutils 2.18?
Comment 2 Oliver Falk 2007-11-07 08:18:01 UTC
(In reply to comment #1)
> Can you try binutils 2.18?

Yes. I just compiled binutils 2.18 and will try a new firefox build. Should be
finished in a few hours :-)
Comment 3 Oliver Falk 2007-11-07 10:28:51 UTC
Nice try, but didn't work:

../../dist/lib/libgkcontentsvg_s.a(nsSVGScriptElement.o):/home/oliver/firefox/mozilla/content/svg/content/src/nsSVGScriptElement.cpp:194:
relocation truncated to fit: GPREL16 against symbol `nsSVGAtoms::type' defined
in .sbss section in ../../dist/lib/libgkcontentsvg_s.a(nsSVGAtoms.o)
../../dist/lib/libgkcontentsvg_s.a(nsSVGScriptElement.o):/home/oliver/firefox/mozilla/content/svg/content/src/nsSVGScriptElement.cpp:424:
relocation truncated to fit: GPREL16 against symbol `nsSVGAtoms::href' defined
in .sbss section in ../../dist/lib/libgkcontentsvg_s.a(nsSVGAtoms.o)
../../dist/lib/libgkcontentsvg_s.a(nsSVGScriptElement.o):/home/oliver/firefox/mozilla/content/svg/content/src/nsSVGScriptElement.cpp:175:
relocation truncated to fit: GPREL16 against symbol `nsSVGAtoms::href' defined
in .sbss section in ../../dist/lib/libgkcontentsvg_s.a(nsSVGAtoms.o)
../../dist/lib/libgkcontentsvg_s.a(nsSVGStylableElement.o):/home/oliver/firefox/mozilla/content/svg/content/src/nsSVGStylableElement.cpp:79:
relocation truncated to fit: GPREL16 against symbol `nsSVGAtoms::_class' defined
in .sbss section in ../../dist/lib/libgkcontentsvg_s.a(nsSVGAtoms.o)
../../dist/lib/libgkcontentsvg_s.a(nsSVGRectElement.o):/home/oliver/firefox/mozilla/content/svg/content/src/nsSVGRectElement.cpp:134:
relocation truncated to fit: GPREL16 against symbol `nsSVGAtoms::x' defined in
.sbss section in ../../dist/lib/libgkcontentsvg_s.a(nsSVGAtoms.o)
../../dist/lib/libgkcontentsvg_s.a(nsSVGRectElement.o):/home/oliver/firefox/mozilla/content/svg/content/src/nsSVGRectElement.cpp:146:
relocation truncated to fit: GPREL16 against symbol `nsSVGAtoms::y' defined in
.sbss section in ../../dist/lib/libgkcontentsvg_s.a(nsSVGAtoms.o)
../../dist/lib/libgkcontentsvg_s.a(nsSVGRectElement.o):/home/oliver/firefox/mozilla/content/svg/content/src/nsSVGRectElement.cpp:159:
relocation truncated to fit: GPREL16 against symbol `nsSVGAtoms::width' defined
in .sbss section in ../../dist/lib/libgkcontentsvg_s.a(nsSVGAtoms.o)
../../dist/lib/libgkcontentsvg_s.a(nsSVGRectElement.o):/home/oliver/firefox/mozilla/content/svg/content/src/nsSVGRectElement.cpp:172:
relocation truncated to fit: GPREL16 against symbol `nsSVGAtoms::height' defined
in .sbss section in ../../dist/lib/libgkcontentsvg_s.a(nsSVGAtoms.o)
../../dist/lib/libgkcontentsvg_s.a(nsSVGRectElement.o):/home/oliver/firefox/mozilla/content/svg/content/src/nsSVGRectElement.cpp:184:
relocation truncated to fit: GPREL16 against symbol `nsSVGAtoms::rx' defined in
.sbss section in ../../dist/lib/libgkcontentsvg_s.a(nsSVGAtoms.o)
../../dist/lib/libgkcontentsvg_s.a(nsSVGRectElement.o):/home/oliver/firefox/mozilla/content/svg/content/src/nsSVGRectElement.cpp:197:
relocation truncated to fit: GPREL16 against symbol `nsSVGAtoms::ry' defined in
.sbss section in ../../dist/lib/libgkcontentsvg_s.a(nsSVGAtoms.o)
../../dist/lib/libgkcontentsvg_s.a(nsSVGSVGElement.o):/home/oliver/firefox/mozilla/content/svg/content/src/nsSVGSVGElement.cpp:1555:
additional relocation overflows omitted from the output
collect2: ld returned 1 exit status


BUT: Could it be 2.18 is faster than 2.17? It *feels* a bit faster...
Comment 4 H.J. Lu 2007-11-07 14:33:42 UTC
Can you verify that -fPIC or -mlarge-data is used:

http://www.redhat.com/archives/axp-list/2003-August/msg00039.html
Comment 5 Oliver Falk 2007-11-09 11:56:39 UTC
(In reply to comment #4)
> Can you verify that -fPIC or -mlarge-data is used:
> 
> http://www.redhat.com/archives/axp-list/2003-August/msg00039.html

Only -fPIC is in use. No -msmall-data or -fpic...
Comment 6 H.J. Lu 2007-11-09 13:21:14 UTC
(In reply to comment #5)
> (In reply to comment #4)
> > Can you verify that -fPIC or -mlarge-data is used:
> > 
> > http://www.redhat.com/archives/axp-list/2003-August/msg00039.html
> 
> Only -fPIC is in use. No -msmall-data or -fpic...

It sounds like a compiler bug. When -fPIC is used, GPREL32 should
be generated, instead of GPREL16. I suggest you open a gcc bug report
with nsSVGScriptElement.o as testcase.
Comment 7 Matt Turner 2010-05-04 03:42:10 UTC
Never experienced this in years of running Gentoo. Marking as worksforme. Reopen
if it's somehow still a problem.
Comment 8 Michael Cree 2011-04-02 19:58:29 UTC
This bug has been seen in linking xulrunner, webkit and libreoffice in the last few months on Debian unstable distribution. These programs link successfully if --no-relax is used in the link.  Reopening.
Comment 9 Matt Turner 2011-07-09 20:53:36 UTC
Packages known to require -Wl,--no-relax on alpha as a work-around for this bug:

ocaml
hunderbird
webkit-gtk
xulrunner
jfsutils
firefox
seamonkey

and apparently now gcc-4.6: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47230
Comment 10 Jackie Rosen 2014-02-16 19:31:36 UTC Comment hidden (spam)
Comment 11 Richard Henderson 2014-05-28 20:01:59 UTC
Should be fixed on mainline as of d1c109de72f880ea2a761fccb41f330672674fd9
Comment 12 Uros Bizjak 2015-02-25 20:15:53 UTC
(In reply to Richard Henderson from comment #11)
> Should be fixed on mainline as of d1c109de72f880ea2a761fccb41f330672674fd9

Confirmed that GCC 5.0 builds OK without -Wl,--no-relax workaround.

The workaround in the GCC was removed for 5.0.
Comment 13 Michael Cree 2015-02-27 06:40:48 UTC
(In reply to Uros Bizjak from comment #12)
> (In reply to Richard Henderson from comment #11)
> > Should be fixed on mainline as of d1c109de72f880ea2a761fccb41f330672674fd9
> 
> Confirmed that GCC 5.0 builds OK without -Wl,--no-relax workaround.
> 
> The workaround in the GCC was removed for 5.0.

But interstingly it fails to build with the Debian gcc-5.0 build.
We get:

alpha-linux-gnu-g++   -g -DIN_GCC    -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   -DHAVE_CONFIG_H -static-libstdc++ -static-libgcc  -o cc1plus \
      cp/cp-lang.o c-family/stub-objc.o cp/call.o cp/decl.o cp/expr.o cp/pt.o cp/typeck2.o cp/class.o cp/decl2.o cp/error.o cp/lex.o cp/parser.o cp/ptree.o cp/rtti.o cp/typeck.o cp/cvt.o cp/except.o cp/friend.o cp/init.o cp/method.o cp/search.o cp/semantics.o cp/tree.o cp/repo.o cp/dump.o cp/optimize.o cp/mangle.o cp/cp-objcp-common.o cp/name-lookup.o cp/cxx-pretty-print.o cp/cp-cilkplus.o cp/cp-gimplify.o cp/cp-array-notation.o cp/lambda.o cp/vtable-class-hierarchy.o cp/constexpr.o cp/cp-ubsan.o attribs.o incpath.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-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-cilkplus.o c-family/array-notation-common.o c-family/cilk.o c-family/c-ubsan.o glibc-c.o cc1plus-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  -lisl -lmpc -lmpfr -lgmp -rdynamic -ldl  -lz
libbackend.a(tree-vect-generic.o): In function `gimple_statement_structure':
/«PKGBUILDDIR»/build/gcc/../../src/gcc/gimple.h:1572:(.text+0x2f4): relocation truncated to fit: ELF_LITERAL against `.text'
libbackend.a(tree-vect-generic.o): In function `gimple_has_ops':
/«PKGBUILDDIR»/build/gcc/../../src/gcc/gimple.h:1846:(.text+0x38c): relocation truncated to fit: ELF_LITERAL against `.text'
/«PKGBUILDDIR»/build/gcc/../../src/gcc/gimple.h:1846:(.text+0x3ac): relocation truncated to fit: ELF_LITERAL against `.text'

I.e. the relocation errors have changed from GPREL16 to ELF_LITERAL.  It builds successfully with --no-relax in the link.

Full build log is at:
http://buildd.debian-ports.org/status/fetch.php?pkg=gcc-5&arch=alpha&ver=5-20150226-1&stamp=1425011105
Comment 14 Uros Bizjak 2015-03-27 17:27:10 UTC
(In reply to Michael Cree from comment #13)

> > Confirmed that GCC 5.0 builds OK without -Wl,--no-relax workaround.
> > 
> > The workaround in the GCC was removed for 5.0.
> 
> But interstingly it fails to build with the Debian gcc-5.0 build.

The removal of the GPREL16 failure workaround in GCC has been reverted. The LTO GCC build still fails [1].

I have reopened this PR.

[1] https://gcc.gnu.org/ml/gcc-patches/2015-03/msg00219.html
Comment 15 Jim Wolfe 2020-07-02 04:23:42 UTC
GCC 5.0 builds OK without -Wl,--no-relax workaround.
https://spanishdictionary.cc/