| Summary: | 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' | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | spock128 |
| Component: | Current packages | Assignee: | Mozilla Gentoo Team <mozilla> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | bkohler, matoro_gentoo, sam, sparc |
| Priority: | Normal | Keywords: | PullRequest |
| Version: | unspecified | ||
| Hardware: | Sparc | ||
| OS: | Linux | ||
| See Also: | https://github.com/gentoo/gentoo/pull/26676 | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | 820101 | ||
| Bug Blocks: | 721344, 843998 | ||
| Attachments: | build.log.gz | ||
|
Description
spock128
2019-06-24 03:00:42 UTC
Does spidermonkey:60 build for you? I get the same error as the reporter, on both 52.9.1_pre1 and 60.5.2_p0-r2 Why do we not have a full build.log attached to the bug report? Created attachment 587024 [details]
build.log.gz
Ask and ye
(I dropped sparc keywords on :52) 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. This is fixed on 32-bit with the usual -latomic tweak. The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=29cf769f4de6550851e74829c2011c2e23554cc7 commit 29cf769f4de6550851e74829c2011c2e23554cc7 Author: matoro <matoro@users.noreply.github.com> AuthorDate: 2022-07-10 22:41:17 +0000 Commit: Sam James <sam@gentoo.org> 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 <sam@gentoo.org> eclass/flag-o-matic.eclass | 145 +++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 145 insertions(+) The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=0d064fd26399378fa1ef9e843a6ea8dd325aef4c commit 0d064fd26399378fa1ef9e843a6ea8dd325aef4c Author: matoro <matoro@users.noreply.github.com> AuthorDate: 2022-07-31 02:50:26 +0000 Commit: Sam James <sam@gentoo.org> 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 <sam@gentoo.org> dev-lang/spidermonkey/spidermonkey-60.5.2_p0-r6.ebuild | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) |
