Bug 266402 - clang crashes on math/lean on aarch64 on 13.1-RELEASE and 14-CURRENT
Summary: clang crashes on math/lean on aarch64 on 13.1-RELEASE and 14-CURRENT
Status: New
Alias: None
Product: Base System
Classification: Unclassified
Component: misc (show other bugs)
Version: CURRENT
Hardware: Any Any
: --- Affects Only Me
Assignee: freebsd-toolchain (Nobody)
URL: http://ampere2.nyi.freebsd.org/data/m...
Keywords:
Depends on:
Blocks:
 
Reported: 2022-09-13 21:51 UTC by Yuri Victorovich
Modified: 2022-09-14 00:08 UTC (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Yuri Victorovich freebsd_committer freebsd_triage 2022-09-13 21:51:46 UTC
It looks like this in logs:
> [100% 340/340] : && /usr/bin/c++ -Wall -Wextra -std=c++11  -D LEAN_JSON -D LEAN_MULTI_THREAD -D LEAN_AUTO_THREAD_FINALIZATION -DLEAN_BUILD_TYPE="Release" -D__CLANG__ -D HAS_TCMALLOC -O3 -DNDEBUG -fstack-protector-strong  -pthread shell/CMakeFiles/shell_js.dir/lean_js.cpp.o shell/CMakeFiles/shell_js.dir/server.cpp.o tests/shell/CMakeFiles/shell_test.dir/shell.cpp.o -o tests/shell/shell_test  -Wl,-rpath,/usr/local/lib  libleanstatic.a  /usr/local/lib/libgmp.so  /usr/local/lib/libtcmalloc.so  -lprocstat && :
> *** Signal 11
Comment 1 Mark Millard 2022-09-13 23:58:40 UTC
The:

QUOTE
[100% 340/340] : && /usr/bin/c++ -Wall -Wextra -std=c++11  -D LEAN_JSON -D LEAN_MULTI_THREAD -D LEAN_AUTO_THREAD_FINALIZATION -DLEAN_BUILD_TYPE="Release" -D__CLANG__ -D HAS_TCMALLOC -O3 -DNDEBUG -fstack-protector-strong  -pthread shell/CMakeFiles/shell_js.dir/lean_js.cpp.o shell/CMakeFiles/shell_js.dir/server.cpp.o tests/shell/CMakeFiles/shell_test.dir/shell.cpp.o -o tests/shell/shell_test  -Wl,-rpath,/usr/local/lib  libleanstatic.a  /usr/local/lib/libgmp.so  /usr/local/lib/libtcmalloc.so  -lprocstat && :
END QUOTE

does not look coherent for FreeBSD, especially for aarch64: the lang/gcc*'s
libstdc++ requires the lang/gcc*'s libgcc_s.so.1 for aarch 64 (because
FreeBSD does not provide a compatible /lib/libgcc_s.so.1 : e.g., "version
GCC_4.5.0 required by /usr/local/lib/gcc12/libstdc++.so.6 not found").

For reference (just what I happen to have in place, not necessarily
matching the lang/gcc* from the build that you reference):

# find /usr/local/ -name "libgcc_s.so*" -print | more
/usr/local/lib/gcc12/libgcc_s.so.1
/usr/local/lib/gcc12/libgcc_s.so

# find /usr/local/ -name "libstdc++*" -print | more
/usr/local/lib/gcc12/libstdc++.so.6.0.30
/usr/local/lib/gcc12/libstdc++.so.6
/usr/local/lib/gcc12/libstdc++.a
/usr/local/lib/gcc12/libstdc++.so
/usr/local/lib/gcc12/libstdc++fs.a
/usr/local/lib/gcc12/libstdc++.so.6.0.30-gdb.py

So, with only -Wl,-rpath,/usr/local/lib it is not referencing where to find
the likes of /usr/local/lib/gcc12/libgcc_s.so.1 would be found and instead
ends up with: /lib/libgcc_s.so.1 in use ( or no binding for libgcc_s.so.1 ).

The resulting binding, if any, would end up with issues like:

ld-elf.so.1: /lib/libgcc_s.so.1: version GCC_4.5.0 required by /usr/local/lib/gcc12/libstdc++.so.6 not found

Unless FreeBSD implements the GCC_4.5.0 related symbols involved in
/lib/libgcc_s.so.1 for aarch64, such is a port's problem to solve
by making the likes of (example) /usr/local/lib/gcc12/libgcc_s.so.1
being used instead.
Comment 2 Mark Millard 2022-09-14 00:08:00 UTC
(In reply to Mark Millard from comment #1)

For reference:

Even main does not have GCC_4.5.0 in /lib/libgcc_s.so.1 :

# strings /lib/libgcc_s.so.1 | grep GCC_ | more
GCC_3.0
GCC_3.3
GCC_3.3.1
GCC_3.4
GCC_3.4.2
GCC_3.4.4
GCC_3.5
GCC_4.0.0
GCC_4.2.0
GCC_4.3.0
GCC_4.6.0