I'm trying to compile with a sysroot for Ubuntu 22.04 from a Ubuntu 20.04 image, and I'm having quite a bit of trouble, getting linker errors like these:
/usr/bin/ld: ../build_rootfs/x86_64_jammy/lib/x86_64-linux-gnu/libc.so.6: undefined reference to `_dl_audit_symbind_alt#GLIBC_PRIVATE'
/usr/bin/ld: ../build_rootfs/x86_64_jammy/lib/x86_64-linux-gnu/libc.so.6: undefined reference to `_dl_audit_preinit#GLIBC_PRIVATE'
/usr/bin/ld: ../build_rootfs/x86_64_jammy/lib/x86_64-linux-gnu/libc.so.6: undefined reference to `_dl_fatal_printf#GLIBC_PRIVATE'
/usr/bin/ld: ../build_rootfs/x86_64_jammy/lib/x86_64-linux-gnu/libc.so.6: undefined reference to `__nptl_change_stack_perm#GLIBC_PRIVATE'
clang: error: linker command failed with exit code 1 (use -v to see invocation)
The exact same invocation works fine from a Ubuntu 22.04, using the exact same compiler and exact same sysroot.
Here's my setup:
// test.cpp
int main(){}
Compile command:
clang++ --sysroot ../build_rootfs/x86_64_jammy test.cpp
Where ../build_rootfs/x86_64_jammy is a sysroot created with multistrap (I can share a minimized multistrap config if it's relevant, but considering the same sysroot works fine from Ubuntu 22.04, the sysroot seems to not be the issue.
Things I have tried:
Using lld--same result
Using clang 14, both from apt.llvm.org and from the binary tarball
Notably, GCC is able to compile it by passing -L/usr/lib/x86_64-linux-gnu/9 -L/usr/lib/x86_64-linux-gnu (yes, even when compiling with --sysroot), but this seems strange as this is linking to libraries on the host system. Adding these flags does let the compilation succeed, but compiling from clang on 22.04 works fine without loading any of the system libraries (allegedly).
I assume this is an issue with glibc verisons, but I can't see how the host glibc version would matter when compiling from a sysroot, and it doesn't seem like any of the linker inputs are actually from the host system, so what's going wrong?
This gist has the verbose logs from clang on focal, gcc on focal, and clang on jammy for reference.
Related
I am trying to link an application that is compiled with clang/libc++ to the v8-devel system library on Fedora. However the latter is compiled with gcc/libstdc++ which leads to a linking error for std::unique_ptr, I think due to inlining.
Is there anything I can change in eiher my application code, or the compiler/linker flags (other than -stdlib) , such that my program can be linked to v8-devel while being still compiled with clang+libcxx?
Below a minimal toy example to reproduce the problem on Fedora (in reality, the only compiler that I have available is a custom clang version with libcxx, so switching to libstdc++ is not an option):
#include <libplatform/libplatform.h>
#include <v8.h>
using namespace v8;
int main(){
std::unique_ptr<Platform> platform = platform::NewDefaultPlatform();
V8::InitializePlatform(platform.get());
}
Then on Fedora we do:
# Install dependencies
yum install -y clang libcxx-devel v8-devel
# Try to compile test program
clang++ test.cpp -std=gnu++17 -stdlib=libc++ -lv8 -lv8_libplatform
Which gives the following linker error:
/usr/bin/ld: /tmp/test-9925a1.o: in function `main':
test.cpp:(.text+0x24): undefined reference to `v8::platform::NewDefaultPlatform(int, v8::platform::IdleTaskSupport, v8::platform::InProcessStackDumping, std::__1::unique_ptr<v8::TracingController, std::__1::default_delete<v8::TracingController> >)'
clang-14: error: linker command failed with exit code 1 (use -v to see invocation)
You can automatically run the steps above using this Dockerfile.
I have been trying to compile LLVM/clang from source, both by myself and using this script. I am compiling clang using gcc 11.2, which itself was also built from source, and hence resides in a non-default location on my system (/scratch/opt/gcc-ml-11.2). Note that it only works with a gcc that was compiled with multilib enabled.
The problem is that I can use the compiled clang and clang++ binaries only if I supply the gcc location as follows: --gcc-toolchain=/scratch/opt/gcc-ml-11.2.0. Without that flag, I run into linker errors:
clang test.c -o test
/usr/bin/ld: cannot find crtbeginS.o: No such file or directory
/usr/bin/ld: cannot find -lgcc
/usr/bin/ld: cannot find -lgcc_s
I do not understand why a clang compiled binary needs to link against some kind of gcc library and why clang does not supply the crtbeginS.O file.
I have also tried using the LLVM linker as well as the LLVM standard library for C++ test applications, i.e., "-fuse-ld=lld -stdlib=libc++. This did not help either.
While I could just export CXXFLAGS=--gcc-toolchain=/scratch/opt/gcc-ml-11.2.0, I am not sure whether this is the right approach. Shouldn't clang/LLVM be able to function without a gcc installation?
I have also tried using my clang installation with the --gcc-toolchain=/scratch/opt/gcc-ml-11.2.0 flag to compile clang again, but the new binary also requires the gcc-toolchain flag.
Should I just globally export the path to my gcc toolchain? Why is this necessary? Isn't clang a standalone compiler that - if supplied with the option to use its own standard library - does not require gcc?
Thank you very much for your help!
Best,
Maxbit
I wish to setup Affectiva SDK 4.0.0 for Linux and hence, have started working on example apps from https://github.com/Affectiva/cpp-sdk-samples
I have Ubunutu 16.04, OpenCV 2.4.11, Boost 1.63, cmake 3.8.1, pre-installed gcc 5.5.0 and manually installed gcc 5.4.0 (because I could not find a proper setup for gcc 5.4.1 as required).
When I try to run below command to compile the code from video-demo folder:
g++ video_analyse.cpp -o video_analyse -std=c++11 -I$HOME/affdex-sdk/include -L$HOME/affdex-sdk/lib -I$HOME/sdk-samples/common -l affdex-native -l boost_program_options `pkg-config opencv --cflags --libs`
The error points to below line of code:
shared_ptr<PlottingImageListener> listenPtr(new PlottingImageListener(csvFileStream, draw_display));
And receive error:
/tmp/ccWtKCG0.o: In function `PlottingImageListener::PlottingImageListener(std::basic_ofstream<char, std::char_traits<char> >&, bool)':
video_analyse.cpp:(.text._ZN21PlottingImageListenerC2ERSt14basic_ofstreamIcSt11char_traitsIcEEb[_ZN21PlottingImageListenerC5ERSt14basic_ofstreamIcSt11char_traitsIcEEb]+0x148): undefined reference to `Visualizer::Visualizer()'
collect2: error: ld returned 1 exit status
The exact same error is received with gcc 5.5.0 as well.
If I comment everything starting from that line of code, then the compilation happens successfully.
Please guide me on this. Either on how to install the exact version of gcc 5.4.1 as expected by the SDK dependency OR anything which I might be missing.
Until some weeks ago, using the boost_regex library I used to compile a C++ file test.cpp using the following command.
g++-4.9 -Wall -O3 -march=native -flto -DNDEBUG -o test \
--std=c++14 test.cpp -lboost_regex -pthread
The compilation was working perfectly. But at some point, I needed to upgrade my OS (more precisely, it was Ubuntu 14.04, now it is Ubuntu 16.04).
I kept my local folders with my data, and I also installed the Boost library again in the new system, including boost_regex.
The Boost version in the new system is 1.58, unfortunately I cannot know which Boost version I was using before because it is now deleted.
I try to compile again the same file in the new system, with the same command as above, and the linker says it cannot find two functions called maybe_assign and construct_init. If I replace the -o test option with just -c (i.e. without linking) then the program is compiled without errors.
More precisely, when I try to do linking I get the following errors (they were extremely long, I hade to shorten using ... dots).
In function `boost::re_detail::perl_matcher<...>::match_match()':
undefined reference to `boost::match_results<...>::maybe_assign(boost::match_results<...> const&)'
In function `bool boost::regex_search<...>(...)':
undefined reference to `boost::re_detail::perl_matcher<...>::construct_init(...)'
In function `boost::re_detail::perl_matcher<...>::match_prefix()':
undefined reference to `boost::match_results<...>::maybe_assign(boost::match_results<...> const&)'
collect2: error: ld returned 1 exit status
I really don't know how this is possible, the libraries seem perfectly installed, nothing seems missing, and the compilation was working with a previous OS installation (then I guess older libraries).
At these point my only guess could be that Boost authors removed such functions? (maybe they are obsolete?). But I didn't find any trace of this on internet. If this is the case, how can I know the boost versions in which such functions are available?
Am I doing any mistake? Do you have any suggestions to investigate about this?
TL;DR use gcc5.
Ununtu 16.04 comes with gcc5 by default. Every C++ library in it is compiled with that compiler.
Now there was an incompatible C++ ABI change between gcc4 and gcc5. It made binaries built from C++ sources with gcc4 incompatible by default with binaries built with gcc5. This incompatibility often manifests itself as a bunch of undefined symbols that reference std::string and/or std::list.
The standard library comes built with a dual ABI to support objects built with older compilers. Other libraries like boost, hovever, don't.
I wrote an application on Windows using CPP and BASS, and now I have to get it running on Linux (UBUNTU).
I am using gcc version 4.5.2.
I have bass.lib in my directory from which I try to compile prog.cpp using the following command arguments:
gcc prog.cpp -L. -lbass.lib
But I get the following error:
/usr/bin/ld: cannot find -lbass.lib
collect2: ld returned 1 exit status
I figure that this is a linking error, the compiler is not finding Bass.lib but I have specified as an argument on the command line.
Not sure what to do, any help would be really great.
bass.lib sounds like the windows library. You cannot use libraries generated on windows, (likely generated with the MSVC compiler), on linux.
The linux version of the library seems to be named libbass.so , in which case you'd use -lbass as the linker argument , and possibly other compiler/linker flags as well depending on where on the system you install the library. The bass.txt in the linux download of libbass have a few notes on what to do on Linux.