amazon-linux-2023
amazon-linux-2023 copied to clipboard
amazonlinux
[Bug] - Regression in clang-devel package
Describe the bug
Attempting to compile a C++ program with g++ which links against clang-cpp fails in AL2023.7. This is a regression from AL2023.6.
To Reproduce I reproduced this with docker to get different versions of AL2023
FROM amazonlinux:2023
RUN dnf upgrade -y && \
dnf install -y --allowerasing \
gcc gcc-c++ python3 python3-devel bash make gawk cmake \
which diffutils wget vim sudo \
clang clang-devel \
rpm-build rpm-devel rpmlint coreutils patch rpmdevtools chrpath
RUN useradd .....
USER user
WORKDIR /home/user
RUN echo "int main() { return 0; }" > hello.cpp
WORKDIR /home/user
ENTRYPOINT [ "/bin/bash" ]
I then ran g++ hello.cpp -lclang-cpp inside of the docker container
With amazonlinux:2023.7.20250428.1, I get linker errors. With amazonlinux:2023.6.20250317.2, it works as expected.
The error is
/usr/bin/ld: /usr/lib/gcc/aarch64-amazon-linux/11/../../../../lib64/libclang-cpp.so: undefined reference to `std::condition_variable::wait(std::unique_lock<std::mutex>&)@GLIBCXX_3.4.30'
/usr/bin/ld: /usr/lib/gcc/aarch64-amazon-linux/11/../../../../lib64/libclang-cpp.so: undefined reference to `std::__glibcxx_assert_fail(char const*, int, char const*, char const*)@GLIBCXX_3.4.30'
collect2: error: ld returned 1 exit status
Expected behavior I expect the default system compiler to be able to use another library
Screenshots
This is fixed in clang-devel-15.0.7-3.amzn2023.0.4 which should be on its way in the next release. In the meantime, you can use -Wl,--unresolved-symbols=ignore-in-shared-libs (or the shorter variant -Wl,--allow-shlib-undefined) to avoid the issue.
The problem stems from a complex issue that arised when we added gcc 14 and updated the runtime libraries such as libstdc++ to version 14.
Our original release did what other distros such as SuSE, Debian/Ubuntu etc.. . do which is to simply update the libraries as they are backwards compatible.
However, we found out that in some cases, a symbol has changed semantic (specifically std::condition_variable::wait(std::unique_lock<std::mutex>&) but there could be more, in this case it lost its noexcept attribute). The new library provides both versions of the symbol in order to be compatible with the semantics exposed by the old headers. However, while that works fine for already complied binaries which use the old version, newly compiled binaries with the old compiler (gcc 11) using thus the old headers would end up picking up (incorrectly) the new version of the symbol at link time (which doesn't match the headers) due to the new library replacing globally the old one.
As a result, the libraries in clang-devel ended up picking up a dependency on the new symbol (which is provided by the new library, so it seems to work, but the semantics aren't quite right).
We eventually in our latest update "fixed" this by changing gcc packaging so that the old version of the runtime libraries is bundled in gcc private directory (/usr/lib/gcc/<arch>/11/) and used for linking, thus ensuring that things built with the old compiler are linked against the old version of the runtime library symbols.
The problem of course arises if you try to link with a library that itself was linked against the new runtime libs, and thus wants the new symbol, since the old compiler won't "see" it anymore at link time.
The workaround above tells gcc to ignore undefined symbol requirements coming from shared libs, which in this case is fine since the symbol will be available at runtime, just not at link time.
The fixed clang was properly rebuilt with the fixed gcc as to no longer bring in that dependency since it wasn't correct to begin with.
Great, glad to hear the bug has been fixed and that the fix will be available soon. Thank you
@ozbenh : Thanks for the quick and very thorough explanation! I'm not very familiar with amazon linux or its release schedule. When might that fix in the next release become available? (trying to decide whether to wait for it or use your workaround for a time).
The "normal" schedule is every two weeks but various factors can affect this. I can't promise a date at this stage