1242901 - build fails: `start_kPStaticModules_NSModule' can not be used when making a shared object

Status: RESOLVED FIXED

(Firefox Build System :: General, defect, P1)

Description

[jbrown]

I'm building on 32bit Linux with gcc 4.9.3 (without flto) and binutils 2.26.

The build fails with:

    /usr/bin/ld: ../../xpcom/components/nsComponentManager.o: relocation R_386_GOTOFF against protected data `start_kPStaticModules_NSModule' can not be used when making a shared object
    /usr/bin/ld: final link failed: Bad value
    collect2: error: ld returned 1 exit status

A previuos build with binutils 2.25.1 succeeded.

Comment 1

[Ian Stakenvicius]

Gentoo linux is also running into this, on at least x86_64 but likely all platforms, since binutils-2.26.1 has been made available.:

    INPUT("StaticXULComponentsEnd/StaticXULComponentsEnd.o")

/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.3/../../../../x86_64-pc-linux-gnu/bin/ld: ../../xpcom/components/nsComponentManager.o: relocation R_X86_64_PC32 against protected symbol `end_kPStaticModules_NSModule' can not be used when making a shared object
/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.3/../../../../x86_64-pc-linux-gnu/bin/ld: final link failed: Bad value
collect2: error: ld returned 1 exit status


Of note, this is triggered when ld.bfd is used as the linker -- ld.gold does not trigger the issue.

It seems that the "protected" visibility that is enabled on .kPStaticModule in xpcom/components/Module.h triggers it, as it's been reported that using the following patch from netbsd (which changes visibility from 'protected' to 'default') addresses the issue:

http://cvsweb.netbsd.org/bsdweb.cgi/pkgsrc/www/firefox45/patches/patch-xpcom_components_Module.h?rev=1.1&content-type=text/x-cvsweb-markup

If this patch is a safe/appropriate fix, I'll attach a version that applies cleanly to m-c, etc.

Comment 2

[jbrown]

Could someone of the developers please comment the patch?

Comment 3

[Guo Yunhe]

Same problem on openSUSE 42.1 x64

 0:31.74     INPUT("StaticXULComponentsEnd/StaticXULComponentsEnd.o")
 0:31.74 
 0:31.74 /usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: ../../xpcom/components/nsComponentManager.o: relocation R_X86_64_PC32 against protected symbol `end_kPStaticModules_NSModule' can not be used when making a shared object
 0:31.75 /usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: 最后的链结失败: 错误的值
 0:31.75 collect2: error: ld returned 1 exit status
 0:31.75 /home/sign/hg/mozilla/config/rules.mk:816: recipe for target 'libxul.so' failed
 0:31.75 gmake[5]: *** [libxul.so] Error 1
 0:31.75 /home/sign/hg/mozilla/config/recurse.mk:71: recipe for target 'toolkit/library/target' failed
 0:31.75 gmake[4]: *** [toolkit/library/target] Error 2
 0:31.75 /home/sign/hg/mozilla/config/recurse.mk:32: recipe for target 'compile' failed
 0:31.75 gmake[3]: *** [compile] Error 2
 0:31.75 /home/sign/hg/mozilla/config/rules.mk:539: recipe for target 'default' failed
 0:31.75 gmake[2]: *** [default] Error 2
 0:31.75 /home/sign/hg/mozilla/client.mk:413: recipe for target 'realbuild' failed
 0:31.75 gmake[1]: *** [realbuild] Error 2
 0:31.75 client.mk:168: recipe for target 'build' failed
 0:31.75 gmake: *** [build] Error 2
 0:31.78 1095 compiler warnings present.

Comment 4

[jbrown]

Really no developer who could even comment the patch?! It's a shame!

Comment 5

[Mike Hommey [:glandium]]

If you don't needinfo? someone or attach a patch with a feedback or review flag, things can go unnoticed.

That patch looks fine, but it needs to be attached here with proper authorship information, and a review requested. See https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/How_to_Submit_a_Patch#Submitting_the_patch

Comment 6

[jbrown]

Attachment: fix linking libxul.so with binutils/GNU ld >= 2.26

Patch from http://cvsweb.netbsd.org/bsdweb.cgi/pkgsrc/www/firefox45/patches/#dirlist

Comment 7

[Mike Hommey [:glandium]]

Comment on attachment 8797659 [details] [diff] [review]
fix linking libxul.so with binutils/GNU ld >= 2.26

Review of attachment 8797659 [details] [diff] [review]:
-----------------------------------------------------------------

Please attach a patch in git or mercurial format with authorship, so that it can be applied easily.

Comment 8

[jbrown]

Attachment: fix linking libxul.so with binutils/GNU ld >= 2.26

[Approval Request Comment]
If this is not a sec:{high,crit} bug, please state case for ESR consideration:
User impact if declined: Compilation with binutils/GNU ld >= 2.26 will fail
Fix Landed on Version: next esr45
Risk to taking this patch (and alternatives if risky): NONE if proved ok
String or UUID changes made by this patch: NONE

See https://wiki.mozilla.org/Release_Management/ESR_Landing_Process for more info.

Comment 9

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/cca249d09ef6
Fix linking libxul.so with binutils/GNU ld >= 2.26. r=glandium

Comment 10

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/cca249d09ef6

Comment 11

[Liz Henry (:lizzard) (relman/hg->git project)]

Comment on attachment 8802867 [details] [diff] [review]
fix linking libxul.so with binutils/GNU ld >= 2.26

We limit ESR uplifts to fixes for sec-high and sec-critical bugs, this late in the ESR cycle. This may need to wait for the next major ESR release, 52.