What library do I need to link to use std::list in clang++? - c++

I am trying to use the std::list class in C++, and I need to use clang++ to compile the program. g++ compiles the following program just fine, but I can't figure out how to compile/link it with clang++:
#include <iostream>
#include <list>
int main(){
std::list<int> L;
L.push_back(10);
std::cout << L.back() << std::endl;
return 0;
}
I've tried clang++ -lstdc++ listTest.cpp but still get the following error:
/tmp/listTest-3175a9.o: In function `std::list<int, std::allocator<int> >::_M_insert(std::_List_iterator<int>, int const&)':
listTest.cpp:(.text._ZNSt4listIiSaIiEE9_M_insertESt14_List_iteratorIiERKi[_ZNSt4listIiSaIiEE9_M_insertESt14_List_iteratorIiERKi]+0x31): undefined reference to `std::__detail::_List_node_base::_M_hook(std::__detail::_List_node_base*)'
clang: error: linker command failed with exit code 1 (use -v to see invocation)
Clang version:
clang version 3.4 (tags/RELEASE_34/final)
linux version:
LSB_VERSION=base-4.0-amd64:base-4.0-noarch:core-4.0-amd64:core-4.0-noarch:graphics-4.0-amd64:graphics-4.0-noarch:printing-4.0-amd64:printing-4.0-noarch
Red Hat Enterprise Linux Server release 6.5 (Santiago)

You should provide library arguments after the translation unit that uses them:
clang++ listTest.cpp -lstdc++
I should note that I couldn't reproduce your issue, but that could easily be down to differences in version/configuration (particularly w.r.t. a stdlib implementation selected for use by default).

I solved it on mine (redhat, clang 3.4, gcc 4.7.2).
By default this project was linking against /usr/lib/libstdc++. I have a build of gcc 4.7.2 installed in a separate location; when I add lines analogous to the following to the link step it works fine
-L${GCC_PATH}/lib -Wl,-R${GCC_PATH}/lib
... provided they appear in the link step before analogous statements for /usr/lib.
edit
You can use strace to help diagnose this problem; I did something like the following:
// copy the link step into a temp shell script
strace -f ./temp.sh |& grep -P 'lib(std)?c\+\+'
... which is when I realized I probably needed a different build of the C++ runtime because I saw it was finding and linking against the one in /usr/lib.

Related

How to link libcxx application to a C++ library compiled with gcc

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.

linking against different libc++ for clang14 on macOS 10.13

edit: My question is not related to Link errors using <filesystem> members in C++17 at all!
-lstdc++fs is not available on clang14 for macOS 10.13
edit2: Latest Xcode for macOS 10.13 is clang10, that is another reason for using clang14 from llvm. Also I can not update Xcode because my macOS Is stuck at high-serria
I am compiling the minimal example below with clang14.
#include <iostream>
#include <filesystem>
namespace fs = std::filesystem;
int main()
{
std::cout << "Current path is " << fs::current_path() << '\n';
}
as follows:
clang-14++ path.cpp -std=c++20
which results in a linking error:
ld64.lld: error: undefined symbol: std::__1::__fs::filesystem::__current_path(std::__1::error_code*)
>>> referenced by /var/folders/_z/1q84ymcj36dgx7d2z7ybs6h40000gn/T/path-201e1b.o
clang-14: error: linker command failed with exit code 1 (use -v to see invocation)
running -v outputs the following:
https://pastebin.com/G1PDDkTJ
My understanding is that -lc++ is linking against the system's default libc++ (the one shipped with apple-clang and not the one with shipped clang14)
I verified that by appending
-L/path/to/clang14/lib/folder
before the -lc++
and it did compile and work however, generated the warning:
ld64.lld: warning: /Users/alia/.local/clang_llvm_apple/lib/libc++.dylib has version 11.6.0, which is newer than target minimum of 10.13.0
ld64.lld: warning: /Users/alia/.local/clang_llvm_apple/lib/libunwind.dylib has version 11.6.0, which is newer than target minimum of 10.13.0
any way to tell clang to link against its own default libc++? or should I just alias some command to compile first and then append -L as above and link?
also, does this have any impact or possible gotchas that I should be aware of? I am using clang14 because apple-clang doesn't support address sanitizers.

Clang compiler couldn't find C/C++ standard libraries when I gave a specific target although it works without giving target

I am currently using clang11 on ubuntu to compile any c/c++ code and it works fine but when I tried to compile any code (including any standard library) to assembly code for any specific target like x86_64 (even I have x86_64) riscv with giving a flag that --target=x86_64 or --target=riscv32 I got errors for any standard library that I included in my code. A simple example:
// ex.cpp
#include<iostream>
int main(){
int a = 5;
int b = 3;
std::cout << a - b;
}
Without giving flag for a spesific target works fine:
clang++-11 -S ex.cpp -o ex.s
With --target=riscv32 flag:
clang++-11 --target=riscv32 -S ex.cpp -o ex.s
gives this error:
ex.cpp:1:9: fatal error: 'iostream' file not found
also without standard libraries gives no error even I give a spesific target.
I am searching for a solution for days but I couldn't find any proper solution for this problem, most of them says try to include gnu libraries and subfolders like -I/usr/include/x86_64-linux-gnu/c++/ but it doesn't work for me.
Please don't say use g++ compiler, for adding an optimization I need clang.
Actually I am trying to compile my codes for riscv target, linking with g++ and running with spike (doesn't differ --target=... or -target ...):
clang++-11 -target riscv32-unknown-elf -march=rv32gc -fno-addrsig -S ex.cpp -o ex.s
~/riscv/bin/riscv32-unknown-elf-g++ ex.s -o ex
~/riscv/riscv-isa-sim/build/spike --isa=RV32GC ~/riscv/riscv-pk/build/pk ex
And it works fine without include a standard library.
Now, I want to ask that
Can I solve this problem simply?
or
Can I use clang directly from riscv bin utils like ~/riscv/bin/riscv32-unknown-elf-clang++ (I saw something like this on the net but couldn't find) adding and building a submodule to my riscv directory?
Edit: As #NateEldredge said, for x86_64 target triple should --target=x86_64-linux-gnu but for riscv as a target triple riscv32-unknown-elf I still have the same errors. Is there a proper target flag for riscv any other than --target=riscv32-unknown-elf? Maybe I am missing that point.
I solved my problem by linking compilations with riscv-gnu-toolchain built and also answered a similar question here in detailed: Using Clang to compile for RISC-V
Simply we need cross-compilation.
Further information you can also look here: https://github.com/lowRISC/riscv-llvm#how-can-i-build-upstream-llvmclang-and-use-it-to-cross-compile-for-a-riscv32-target

lli: LLVM ERROR: Cannot select: X86ISD::WrapperRIP TargetGlobalTLSAddress:i64

Running the following code with clang++ -S -emit-llvm main.cpp && lli main.ll on Linux(Debian)
#include <future>
int main () {
return std::async([]{return 1;}).get();
}
fails to run on lli due to the following error:
LLVM ERROR: Cannot select: 0xd012e0:
i64 = X86ISD::WrapperRIP TargetGlobalTLSAddress:i64<i8** #_ZSt15__once_callable> 0 [TF=10]
0xd020c0: i64 = TargetGlobalTLSAddress<i8** #_ZSt15__once_callable> 0 [TF=10]
In function: _ZSt9call_onceIMNSt13__future_base13_State_baseV2EFvPSt8functionIFSt10unique_ptrINS0_12_Result_baseENS4_8_DeleterEEvEEPbEJPS1_S9_SA_EEvRSt9once_flagOT_DpOT0_
Questions:
What does it mean?
Are there any compiler-flags that fix this problem?
using -stdlib=libc++ compiles and runs successfully*; what specific features is libstdc++ using that cause this issue ?
EDIT:
The motivation behind this question is to understand the differences between libc++ and libstdc++ that leads to this specific error message (on Linux) in llvm's orcjit.
On OSX gcc has been deprecated and clang uses by default libc++.
To reproduce this error on OSX you probably have to install gcc & use -stdlib=libstdc++.
Here is the llvm-ir (it's unfortunately to big to embed it here directly)
EDIT:
The error turned out to be caused by the lack of TLS support in the JITer. This answer describes another problem concerned with linking and lli.
If you have a look at the generated IR from clang++ -std=c++11 -S -emit-llvm test.cpp, you will find that many of the symbols, e.g. _ZNSt6futureIiE3getEv, are only declared, but never defined. The linker is never called, since -S "Only run[s] preprocess and compilation steps" (clang --help).
lli only executes the IR Module and does no "implicit" linking, how is it supposed to know which libraries to link in?
There are different solutions to this, depending on why you are using lli:
compile and link the IR Module: llc main.cpp && clang++ -lpthread main.s (pthread is required s. What is the correct link options to use std::thread in GCC under linux?)
(unconfirmed) use LD_PRELOAD="x.so y.so" to force-load the libraries before running lli
JIT the module programmatically and use LoadLibraryPermanently(nullptr) (adds symbols of the program into the search space) and LoadLibraryPermanently(file, err) for additional libs (s. http://llvm.org/docs/doxygen/html/classllvm_1_1sys_1_1DynamicLibrary.html)
I can only guess as to why libc++ works for you since it fails on my machine, but presumably it's the case because it is loaded into lli already and lli calls sys::DynamicLibrary::LoadLibraryPermanently(nullptr) to add the program's symbols to its JIT search space (s. https://github.com/llvm-mirror/llvm/blob/release_40/tools/lli/OrcLazyJIT.cpp#L110).
The LLVM-dev mailinglist pointed out:
What does it mean?
The llvm-backend in orcjit does currently not support thread-local storage(TLS)
a minimal example is:
extern thread_local int tls;
int main() {
tls = 42;
return 0;
}
using -stdlib=libc++ compiles and runs successfully*; what specific features is libstdc++ using that cause this issue ?
this works because libc++ future::get implementation does not use thread_local keyword.
Are there any compiler-flags that fix this problem?
currently there is no solution.
Using lli -relocation-model=pic trades this problem with a relocation failure.

Undefined reference to boost::random::random_device constructor and destructor on MinGW-w64 gcc

My OS is Windows 7 64-bit and C++ compiler I'm using is:
g++ (i686-posix-dwarf-rev0, Built by MinGW-W64 project) 5.3.0
And I installed Boost version 1.60 using:
bootstrap.bat mingw
b2 install target=gcc
Then I tested is it working, using examples from Boost.Random tutorial.
With the first two everything was fine, but the third one gave linker errors about boost::random::random_device. I minimized the code to have only this:
// Compiled with:
// g++ -IC:/Boost/include/boost-1_60
// -LC:/Boost/lib -lboost_random-mgw53-mt-1_60
// main.cpp
#include "boost/random/random_device.hpp"
int main() {
boost::random::random_device rng;
}
And I get the following errors:
C:\Users\Daniel\AppData\Local\Temp\cc5DfdjZ.o:main.cpp:(.text+0x15):
undefined reference to `boost::random::random_device::random_device()'
C:\Users\Daniel\AppData\Local\Temp\cc5DfdjZ.o:main.cpp:(.text+0x20):
undefined reference to `boost::random::random_device::~random_device()'
collect2.exe: error: ld returned 1 exit status
Here, on SO, I found that someone with similar problem added -lboost_system to flags, but for me it didn't helped.
Does anyone have any idea, why it isn't working? I checked, and I have random_device.hpp header in my Boost folder, with declarations of random_device() and ~random_device() in it.
I found what was wrong - the g++ command syntax, that I wanted to use to compile and link my code.
As I wrote in my question, I do this that way:
g++ -IC:/Boost/include/boost-1_60 -LC:/Boost/lib -lboost_random-mgw53-mt-1_60 main.cpp
While the correct one is with main.cpp (or any other source code file(s), that we want to include in compiling process) before the -L and -l flags.
For example:
g++ -IC:/Boost/include/boost-1_60 main.cpp -LC:/Boost/lib -lboost_random-mgw53-mt-1_60
or even
g++ main.cpp -IC:/Boost/include/boost-1_60 -LC:/Boost/lib -lboost_random-mgw53-mt-1_60
Hope it will help anyone, who will make such silly mistake too.