Bug 688574 – dev-lang/spidermonkey-60 on sparc - Unified_cpp_js_src1.o: in function `js::PromiseObject::getID()': Unified_cpp_js_src1.cpp:(.text+0x1f43c): undefined reference to `__atomic_fetch_add_8'

• Status: RESOLVED FIXED
• Product: Gentoo Linux

[Description spock128 2019-06-24 03:00:42 UTC]

Compile error emerging spidermonkey on sparc:

# emerge -1v =dev-lang/spidermonkey-52.9.1_pre1
...
/usr/lib/gcc/sparc-unknown-linux-gnu/8.3.0/../../../../sparc-unknown-linux-gnu/bin/ld: Unified_cpp_js_src1.o: in function `js::PromiseObject::getID()':
Unified_cpp_js_src1.cpp:(.text+0x1f43c): undefined reference to `__atomic_fetch_add_8'
/usr/lib/gcc/sparc-unknown-linux-gnu/8.3.0/../../../../sparc-unknown-linux-gnu/bin/ld: Unified_cpp_js_src20.o: in function `js::gc::NextCellUniqueId(JSRuntime*)':
Unified_cpp_js_src20.cpp:(.text+0x16858): undefined reference to `__atomic_fetch_add_8'
collect2: error: ld returned 1 exit status


Was able to work around the error by using package.env to supply:

LDFLAGS="-latomic"

[Comment 1 Matt Turner 2019-06-24 17:32:57 UTC]

Does spidermonkey:60 build for you?

[Comment 2 Ben Kohler 2019-06-24 21:56:34 UTC]

I get the same error as the reporter, on both 52.9.1_pre1 and 60.5.2_p0-r2

[Comment 3 Jory A. Pratt 2019-08-16 00:24:26 UTC]

Why do we not have a full build.log attached to the bug report?

[Comment 4 Ben Kohler 2019-08-16 01:33:56 UTC]

Created attachment 587024 [details]
build.log.gz

Ask and ye

[Comment 5 Matt Turner 2019-09-03 06:12:12 UTC]

(I dropped sparc keywords on :52)

[Comment 6 Rolf Eike Beer 2020-02-19 13:49:18 UTC]

You use -mcpu=ultrasparc, that should already support atomic operations on 8 byte values. So it's probably just that these instructions are not used for no reason.

[Comment 7 matoro 2022-05-13 19:34:11 UTC]

This is fixed on 32-bit with the usual -latomic tweak.

[Comment 8 Larry the Git Cow 2022-07-20 23:35:21 UTC]

The bug has been referenced in the following commit(s):

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=29cf769f4de6550851e74829c2011c2e23554cc7

commit 29cf769f4de6550851e74829c2011c2e23554cc7
Author:     matoro <[e-mail]>
AuthorDate: 2022-07-10 22:41:17 +0000
Commit:     Sam James <[e-mail]>
CommitDate: 2022-07-20 23:35:14 +0000

    flag-o-matic.eclass: implement append-atomic-flags
    
    My take on implementing bug 820101 as conservatively as possible. This
    will append -latomic only when absolutely necessary (even though it's
    probably not required to be that conservative due to our use of
    --as-needed).
    
    This will take flags into account when testing as well. For example, if
    you compile with -march=i386, this would require linking libatomic even
    if the same toolchain with a higher -march level would not require it.
    So rebuilding the same package with the same flags may change whether
    -latomic is linked at build time if the CFLAGS change. Another instance
    might be switching from GCC to clang - the former requires explicitly
    linking -latomic, while the latter does not even HAVE libatomic (see bug
    820095) as all atomic intrinsics are built-in internally. This function
    would safely detect this and not append -latomic.
    
    There is an optional parameter [bytes]. You can use this if you want to
    be specific about what size atomic support is required. For example,
    there are several platforms like MIPS where the 32-bit version has 1-,
    2-, and 4-byte atomics builtin but requires libatomic linkage for 8-byte
    atomics. If your program only requires, say, 4-byte atomics, you can use
    append-atomic-flags 4 and this will then not attempt to link libatomic
    on 32-bit MIPS.
    
    I tested using this to solve bug 688574 on 32-bit SPARC.
    
    Bug: https://bugs.gentoo.org/688574
    Bug: https://bugs.gentoo.org/820095
    Closes: https://bugs.gentoo.org/820101
    Closes: https://github.com/gentoo/gentoo/pull/26334
    Signed-off-by: Sam James <[e-mail]>

 eclass/flag-o-matic.eclass | 145 +++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 145 insertions(+)

[Comment 9 Larry the Git Cow 2022-07-31 03:54:47 UTC]

The bug has been closed via the following commit(s):

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=0d064fd26399378fa1ef9e843a6ea8dd325aef4c

commit 0d064fd26399378fa1ef9e843a6ea8dd325aef4c
Author:     matoro <[e-mail]>
AuthorDate: 2022-07-31 02:50:26 +0000
Commit:     Sam James <[e-mail]>
CommitDate: 2022-07-31 03:50:51 +0000

    dev-lang/spidermonkey: conditionally link libatomic
    
    Closes: https://bugs.gentoo.org/688574
    Closes: https://github.com/gentoo/gentoo/pull/26676
    Signed-off-by: Sam James <[e-mail]>

 dev-lang/spidermonkey/spidermonkey-60.5.2_p0-r6.ebuild | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)