hwasan_symbolize is actually an 64-bit-only feature, and was
accidentally included before. Replace the arch opt-out list, with an
opt-in one and a comment pointing to HWASAN_SUPPORTED_ARCH.
i386 is not in the ALL_ORC_SUPPORTED_ARCH list. Previously, the package
shipped liborc_rt-x86_64.a, but since we don't ship amd64 multilib
binaries anymore, remove the reference.
Faidon Liambotis [Wed, 10 Jan 2024 07:32:21 +0000 (09:32 +0200)]
Revert "Enable COMPILER_RT_BUILD_BUILTINS for armel"
FTBFSes with:
FAILED: CMakeFiles/clang_rt.builtins-arm.dir/arm/sync_fetch_and_add_4.S.o
/<<PKGBUILDDIR>>/build-llvm/./bin/clang -target arm-linux-gnueabi -DVISIBILITY_HIDDEN -O3 -DNDEBUG -fno-lto -std=c11 -fPIC -fno-builtin -fvisibility=hidden -fomit-frame-pointer -DCOMPILER_RT_HAS_FLOAT16 -MD -MT CMakeFiles/clang_rt.builtins-arm.dir/arm/sync_fetch_and_add_4.S.o -MF CMakeFiles/clang_rt.builtins-arm.dir/arm/sync_fetch_and_add_4.S.o.d -o CMakeFiles/clang_rt.builtins-arm.dir/arm/sync_fetch_and_add_4.S.o -c /<<PKGBUILDDIR>>/compiler-rt/lib/builtins/arm/sync_fetch_and_add_4.S
In file included from /<<PKGBUILDDIR>>/compiler-rt/lib/builtins/arm/sync_fetch_and_add_4.S:14:
/<<PKGBUILDDIR>>/compiler-rt/lib/builtins/arm/sync-ops.h:22:2: error: DMB is only supported on ARMv6+
22 | #error DMB is only supported on ARMv6+
| ^
This was despite an upstream commit labeled "[compiler-rt] support
armv4t". Perhaps something going on with the way we configure? Revert
for the time being, until (if) someone cares.
Convert libclang-common-*-dev to Arch: all/M-A: foreign
libclang-common-*-dev is an Architecture: any package, possibly due to
the fact that it contained compiler-rt before it was split off to a
separate package. It is not marked as Multi-Arch: same, despite the
hinter suggesting to do so, presumably due to identical files.
Convert it to Architecture: all / Multi-Arch: foreign instead. This
requires the removal of the arch: any dependency libllvm17, which is
spurious anyway. However, for extra safety, add version specifiers to
other packages that do depend on (an unversioned) libllvm17, such as
clang.
Mark documentation packages as Multi-Arch: foreign
..and convert clang-*-examples from Architecture: any -> all.
Identified by the multiarch hinter:
* clang-17-examples could be converted to Architecture: all and marked Multi-Arch: foreign
* clang-17-doc could be marked Multi-Arch: foreign
* libomp-17-doc could be marked Multi-Arch: foreign
* llvm-17-doc could be marked Multi-Arch: foreign
sparc/sparc-D98574-clang-def.patch and
sparc/sparc-D98575-compiler-rt.patch are not in debian/patches/series so
it's safe to drop them. D98574 is now merged, D98575 is abandoned, due
to it being fixed elsewhere, so there's no chance they're going to be
revived either.
Enable COMPILER_RT_DEFAULT_TARGET_ONLY for all archs
This commit does two things in one go:
1) Enable COMPILER_RT_DEFAULT_TARGET_ONLY for i386 and amd64:
Right now i386/amd64 are building compiler-rt for each other, in
addition to themselves.:
- libclang-rt-17-dev:amd64 is also shipping the i386 builtins, and
Depending on libc6-i386:amd64/lib32stdc++:amd64.
- libclang-rt-17-dev:i386 is also shipping the x86_64 built-ins, and
Depending on libc6-amd64:i386/lib64stdc++6:i386/lib64atomic1:i386.
Beyond the extra cruft in files and dependencies, this means that the
amd64/i386 packages are shipping conflicting files, and dpkg is refusing
to unpack one in the presence of the other (an RC bug in itself). This
is also identified by the multiarch hinter with the following message:
libclang-rt-17-dev conflicts on 78 files starting with /usr/lib/llvm-17/lib/clang/17/lib/linux/ on amd64 <-> i386
Let users who want to build e.g. 32-bit binaries in amd64 use multi-arch
for this use case, by installing libclang-rt-17-dev:i386. The
alternative would be to support multi-lib, and ship additional packages
such as libclang-rt-17-dev-i386:amd64 (and vice-versa), but this feels
like an overkill. Multi-lib remains still a possibility with (Debian's)
clang's default, libgcc (lib32gcc/lib64gcc) as well.
This was being passed in an opt-in basis, via STAGE_ALL_CMAKE_EXTRA for
the following architectures:
* armel
* armhf
* powerpc
* sparc
* sparc64
* s390x
* mips64el
* hurd-i386
So, with i386/amd64 also opting-in, this leaves only a few remaining
Debian architectures.
Furthermore, upon inspecting compiler-rt/cmake/base-config-ix.cmake, it
looks like the only architectures that are actually building for
additional (non-default) targets are i386, amd64, powerpc (note: not
ppc64el!), mips*, and arm. Turns out we've disabled that for all of them
now.
Therefore, pass COMPILER_RT_DEFAULT_TARGET_ONLY=ON to all architectures
unconditionally, and thus reduce an additional variation factor.
libc++abi-*-dev is necessary when using libc++-*-dev:
$ apt install clang-17 libc++-17-dev
$ clang++-17 -stdlib=libc++ -o hello hello.cpp
/usr/bin/ld: cannot find -lc++abi: No such file or directory
clang++-17: error: linker command failed with exit code 1 (use -v to see invocation)
Note that the libc++1-* -> libc++abi-* dependency already exists.
Matthias Klose [Tue, 5 Dec 2023 08:42:31 +0000 (09:42 +0100)]
* Set the cpu defaults for the ARM32 architectures:
- armel: arm926ej-s. Closes: #1056115.
- armhf: cortex-a8.
Thanks to Arnd Bergmann and Ard Biesheuvel for the fixes.
Sylvestre Ledru [Tue, 5 Dec 2023 06:41:52 +0000 (07:41 +0100)]
Revert " * Set the cpu defaults for the ARM32 architectures:"
for causing this issue:
https://lore.kernel.org/lkml/20231204225148.GA2094126@dev-arch.thelio-3990X/T/
projects / llvm-toolchain.git / log