../../js/src/js-dtrace.o:(.SUNW_dof+0x360): undefined reference to `$dtrace7737474._ZN2js14NewObjectCache16newObjectFromHitEP9JSContextiNS_2gc11InitialHeapE' /usr/bin/ld: final link failed: Bad value c++: error: linker command failed with exit code 1 (use -v to see invocation) gmake[6]: *** [/wrkdirs/usr/ports/www/firefox/work/firefox-51.0.1/config/rules.mk:802: libxul.so] Error 1
This is a bit strange. I had hit this error while testing in preparation for r313262, but had fixed it before committing. I'll try to reproduce this.
The problem seems to be related to GNU ld (I had only tested the build with lld) and -ffunction-sections. Two objects that get linked into libxul.so contain the same weak symbol. There's a DTrace probe in the corresponding function: > readelf -s Unified_cpp_js_src27.o | grep _ZN2js14NewObjectCache16newObjectFromHitEP9JSC 747: 0000000000000000 518 FUNC WEAK HIDDEN 152 _ZN2js14NewObjectCache16newObjectFromHitEP9JSContextiNS_2gc11InitialHeapE 1261: 0000000000000000 518 FUNC GLOBAL HIDDEN 152 $dtrace6188451._ZN2js14NewObjectCache16newObjectFromHitEP9JSContextiNS_2gc11InitialHeapE > readelf -s jsarray.o | grep _ZN2js14NewObjectCache16newObjectFromHitEP9JSC 382: 0000000000000000 518 FUNC WEAK HIDDEN 405 _ZN2js14NewObjectCache16newObjectFromHitEP9JSContextiNS_2gc11InitialHeapE 567: 0000000000000000 518 FUNC GLOBAL HIDDEN 405 $dtrace6195329._ZN2js14NewObjectCache16newObjectFromHitEP9JSContextiNS_2gc11InitialHeapE > readelf -s js-dtrace.o | grep _ZN2js14NewObjectCache16newObjectFromHitEP9JSC 44: 0000000000000000 0 FUNC GLOBAL DEFAULT UND $dtrace6188451._ZN2js14NewObjectCache16newObjectFromHitEP9JSContextiNS_2gc11InitialHeapE 57: 0000000000000000 0 FUNC GLOBAL DEFAULT UND $dtrace6195329._ZN2js14NewObjectCache16newObjectFromHitEP9JSContextiNS_2gc11InitialHeapE With r313262, we emit alises for the symbols. It seems that ld merges the sections, and ends up leaving one the aliases orphaned: > ld -r -o test.o jsarray.o Unified_cpp_js_src27.o > readelf -s test.o | grep _ZN2js14NewObjectCache16newObjectFromHitEP9JSC 1231: 0000000000000000 0 FUNC GLOBAL HIDDEN UND $dtrace6188451._ZN2js14NewObjectCache16newObjectFromHitEP9JSContextiNS_2gc11InitialHeapE 1438: 0000000000000000 518 FUNC GLOBAL HIDDEN 476 $dtrace6195329._ZN2js14NewObjectCache16newObjectFromHitEP9JSContextiNS_2gc11InitialHeapE 1667: 0000000000000000 518 FUNC WEAK HIDDEN 476 _ZN2js14NewObjectCache16newObjectFromHitEP9JSContextiNS_2gc11InitialHeapE However, the .SUNW_dof section has a relocation for this symbol, so the final link fails. I'm not sure if this behaviour is a bug in ld. It seems to me that we might be able address this by avoiding the "$dtrace" uniquifier for aliases of weak symbols.
I have a fix which addresses this. However, it's working around some linker behaviour that I don't understand; I've asked one of the LLD developers for some clarification. If I don't hear back today I'll commit the workaround as a temporary measure.
A commit references this bug: Author: markj Date: Fri Feb 10 02:01:32 UTC 2017 New revision: 313504 URL: https://svnweb.freebsd.org/changeset/base/313504 Log: When patching USDT probes, use non-unique names for aliases of weak symbols. Aliases are normally given names that include a key that's unique for each input object file. This, for example, ensures that aliases for identically named local symbols in different object files don't conflict. However, in some cases the static linker will leave an undefined alias after merging identical weak symbols, resulting in a link error. A non-unique name allows the aliases to be merged as well. PR: 216871 X-MFC With: r313262 Changes: head/cddl/contrib/opensolaris/lib/libdtrace/common/dt_link.c