Bug 243958 - net-p2p/libtorrent-rasterbar : Fails to build on FreeBSD 12.1-RELEASE-p1 powerpc 32 bit : libtorrent-rasterbar.so.1.2.3: undefined reference to `__atomic_compare_exchange_8'
Summary: net-p2p/libtorrent-rasterbar : Fails to build on FreeBSD 12.1-RELEASE-p1 powe...
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: powerpc Any
: --- Affects Only Me
Assignee: Piotr Kubaj
Depends on:
Reported: 2020-02-07 13:43 UTC by canardo
Modified: 2020-04-20 19:00 UTC (History)
5 users (show)

See Also:
yuri: maintainer-feedback+

patch (445 bytes, patch)
2020-04-05 02:29 UTC, Piotr Kubaj
no flags Details | Diff
v2 (443 bytes, patch)
2020-04-05 02:30 UTC, Piotr Kubaj
no flags Details | Diff
v3 (1.10 KB, patch)
2020-04-19 14:31 UTC, Piotr Kubaj
no flags Details | Diff
v4 (506 bytes, patch)
2020-04-19 22:09 UTC, Piotr Kubaj
no flags Details | Diff
patch (866 bytes, patch)
2020-04-19 23:47 UTC, Yuri Victorovich
no flags Details | Diff
v5 (683 bytes, patch)
2020-04-20 15:41 UTC, Piotr Kubaj
yuri: maintainer-approval+
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description canardo 2020-02-07 13:43:51 UTC
Problem found when building net-p2p/libtorrent-rasterbar on FreeBSD 12.1-RELEASE-p1 r354992 GENERIC powerpc 32 bit, running on Apple Powerbook 17".

/usr/ports/net-p2p/libtorrent-rasterbar # make clean
===>  Cleaning for libtorrent-rasterbar-1.2.3
/usr/ports/net-p2p/libtorrent-rasterbar # make -DBATCH install clean
===>  License BSD3CLAUSE accepted by the user
===>   libtorrent-rasterbar-1.2.3 depends on file: /usr/local/sbin/pkg - found
===> Fetching all distfiles required by libtorrent-rasterbar-1.2.3 for building
===>  Extracting for libtorrent-rasterbar-1.2.3
[169/176] : && /usr/local/bin/g++9  -O2 -pipe  -fstack-protector-strong -Wl,-rpath=/usr/local/lib/gcc9  -Wl,-rpath=/usr/local/lib/gcc9 -O2 -pipe  -fstack-protector-strong -Wl,-rpath=/usr/local/lib/gcc9  -Wl,-rpath=/usr/local/lib/gcc9  -L/usr/local/lib -liconv  -fstack-protector-strong -Wl,-rpath=/usr/local/lib/gcc9 -L/usr/local/lib/gcc9 examples/CMakeFiles/simple_client.dir/simple_client.cpp.o  -o examples/simple_client  -Wl,-rpath,/usr/ports/net-p2p/libtorrent-rasterbar/work/.build  libtorrent-rasterbar.so.1.2.3  -pthread  /usr/lib/libssl.so  /usr/lib/libcrypto.so  /usr/local/lib/libboost_system.so && :
FAILED: examples/simple_client 
: && /usr/local/bin/g++9  -O2 -pipe  -fstack-protector-strong -Wl,-rpath=/usr/local/lib/gcc9  -Wl,-rpath=/usr/local/lib/gcc9 -O2 -pipe  -fstack-protector-strong -Wl,-rpath=/usr/local/lib/gcc9  -Wl,-rpath=/usr/local/lib/gcc9  -L/usr/local/lib -liconv  -fstack-protector-strong -Wl,-rpath=/usr/local/lib/gcc9 -L/usr/local/lib/gcc9 examples/CMakeFiles/simple_client.dir/simple_client.cpp.o  -o examples/simple_client  -Wl,-rpath,/usr/ports/net-p2p/libtorrent-rasterbar/work/.build  libtorrent-rasterbar.so.1.2.3  -pthread  /usr/lib/libssl.so  /usr/lib/libcrypto.so  /usr/local/lib/libboost_system.so && :
/usr/local/bin/ld: libtorrent-rasterbar.so.1.2.3: undefined reference to `__atomic_compare_exchange_8'
/usr/local/bin/ld: libtorrent-rasterbar.so.1.2.3: undefined reference to `__atomic_load_8'
/usr/local/bin/ld: libtorrent-rasterbar.so.1.2.3: undefined reference to `__atomic_store_8'
/usr/local/bin/ld: libtorrent-rasterbar.so.1.2.3: undefined reference to `__atomic_fetch_add_8'
collect2: error: ld returned 1 exit status
ninja: build stopped: subcommand failed.
===> Compilation failed unexpectedly.
Try to set MAKE_JOBS_UNSAFE=yes and rebuild before reporting the failure to
the maintainer.
*** Error code 1

make: stopped in /usr/ports/net-p2p/libtorrent-rasterbar

NB: net-p2p/py-libtorrent-rasterbar/ is currently marked as broken, I don't know if it is related to problem described above.
Comment 1 Yuri Victorovich freebsd_committer 2020-02-07 14:56:55 UTC
This is the question to compiler people that PPC doesn't support __atomic_compare_exchange_8.
Comment 2 daniel.engberg.lists 2020-02-09 16:33:57 UTC
I think the "easy" solution is to force GCC (not base GCC) on PPC 32-bit although I haven't tried it myself.
Comment 3 Piotr Kubaj freebsd_committer 2020-04-05 02:29:17 UTC
Created attachment 213080 [details]

Is that ok? Builds for me on 12.1.
Comment 4 Piotr Kubaj freebsd_committer 2020-04-05 02:30:23 UTC
Created attachment 213081 [details]

Remove empty line.
Comment 5 canardo 2020-04-05 09:22:31 UTC
Using patch above, build was successful !
Comment 6 Piotr Kubaj freebsd_committer 2020-04-19 14:31:55 UTC
Created attachment 213565 [details]

Better patch.
- instead of using LLVM 9, use GCC. On powerpc head, build fails with LLVM 9 (but completes with 10 or GCC). GCC should work just about everywhere.
- -DBOOST_ASIO_DISABLE_STD_EXPERIMENTAL_STRING_VIEW is necessary because boost wants to include headers that are not available in GCC
- Add USES=localbase:ldflags instead of modifying LDFLAGS manually.
Comment 7 Yuri Victorovich freebsd_committer 2020-04-19 19:29:39 UTC
(In reply to Piotr Kubaj from comment #6)


I don't think that we should switch to gcc because one of the architectures has issues with clang. IMO, the correct solution would be to use gcc on that architecture.

Comment 8 Mark Millard 2020-04-19 19:40:39 UTC
(In reply to Piotr Kubaj from comment #6)

There is also the issue of 32-bit powerpc on head potentially
hitting the -maix-struct-return (system clang) vs.
-msvr4-struct-return (gcc*) ABI mismatch at interfaces
that mix code from the two contexts (if any).

https://reviews.llvm.org/D73290 still has not been
adopted by llvm/clang (to match gcc*).
Comment 9 Piotr Kubaj freebsd_committer 2020-04-19 22:09:01 UTC
Created attachment 213581 [details]

Use GCC only on powerpc and add necessary CXXFLAGS there.

Unfortunately, LLVM9 will still be installed as build dependency, there doesn't seem to be a way for adding it to dependencies everywhere but on powerpc.
Comment 10 Yuri Victorovich freebsd_committer 2020-04-19 23:47:44 UTC
Created attachment 213583 [details]

Wouldn't this patch be better?
Comment 11 Mark Millard 2020-04-20 01:49:55 UTC
(In reply to Piotr Kubaj from comment #9)

For head, if gcc* is to match the system clang code
that is currently produced by default, gcc* needs to
be told to use -maix-struct-return instead of its
default -msvr4-struct-return .

It will be this way until system-clang itself is
updated to use the historical -msvr4-struct-return
style that was in use prior to the conversion to
using clang as the system compiler for 32-bit

This, unfortunately, is a mismatch with prior-to-head
versions of 32-bit FreeBSD: for those -maix-struct-return
in a gcc* would be wrong and would introduce an ABI

I'll note that, when code on head hits the ABI
difference, it treats non-pointer-values as pointer
values and tries to dereference or update memory
through the garbage addresses.

(FYI: I'm a tester of the llvm proposal, so my context
is non-default for the system-clang behavior for
targeting 32-bit powerpc.)
Comment 12 Piotr Kubaj freebsd_committer 2020-04-20 15:41:20 UTC
Created attachment 213605 [details]

Thanks, your patch is much better, I thought adding dependencies after including bsd.port.options was impossible. But since base LLVM works just fine, we can just abandon the idea of using GCC. Is that OK with you?
Comment 13 Piotr Kubaj freebsd_committer 2020-04-20 15:43:23 UTC
For the record, LLVM9 fails at configure step with:
    : && /usr/local/bin/clang90 -O2 -pipe  -fstack-protector-strong -fno-strict-aliasing  -L/usr/local/lib -liconv  -fstack-protector-strong CMakeFiles/cmTC_ccceb.dir/testCCompiler.c.o  -o cmTC_ccceb   && :
    Stack dump:
    0.	Program arguments: /usr/local/llvm90/bin/ld --eh-frame-hdr -dynamic-linker /libexec/ld-elf.so.1 --enable-new-dtags -m elf32ppc_fbsd -o cmTC_ccceb /usr/lib/crt1.o /usr/lib/crti.o /usr/lib/crtbegin.o -L/usr/local/lib -L/usr/lib -liconv CMakeFiles/cmTC_ccceb.dir/testCCompiler.c.o -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/lib/crtend.o /usr/lib/crtn.o 
    #0 0x5208ed8c llvm::sys::PrintStackTrace(llvm::raw_ostream&) (/usr/local/llvm90/lib/libLLVM-9.so+0x1ba9d8c)
    #1 0x5208f3a4 (/usr/local/llvm90/lib/libLLVM-9.so+0x1baa3a4)
    #2 0x5208ca44 llvm::sys::RunSignalHandlers() (/usr/local/llvm90/lib/libLLVM-9.so+0x1ba7a44)
    #3 0x5208f738 (/usr/local/llvm90/lib/libLLVM-9.so+0x1baa738)
    #4 0x504ac184 (/lib/libthr.so.3+0x26184)
    clang-cpp: error: unable to execute command: Segmentation fault (core dumped)
    clang-cpp: error: linker command failed due to signal (use -v to see invocation)

Base LLVM10 works.
Comment 14 Yuri Victorovich freebsd_committer 2020-04-20 16:03:48 UTC
(In reply to Piotr Kubaj from comment #13)


Please also add a comment on why it's needed to treat ARCH=powerpc in a different way.

Comment 15 commit-hook freebsd_committer 2020-04-20 19:00:47 UTC
A commit references this bug:

Author: pkubaj
Date: Mon Apr 20 19:00:12 UTC 2020
New revision: 532216
URL: https://svnweb.freebsd.org/changeset/ports/532216

  net-p2p/libtorrent-rasterbar: fix build on powerpc head

  On powerpc head, base LLVM 10 works fine, but LLVM 9 from ports crashes with segfault.

  PR:		243958
  Reported by:	canardo909@gmx.com
  Approved by:	yuri (maintainer)