I'm trying to learn C++ deeper by reading source of STL as well as debugging it, so I want to link libstdc++ statically to my program, and it works fine using g++. However, how can I achieve the same thing with clang++ in llvm?
In another way, the question is, what is the clang++ equivalent of -static-libgcc?
Makefile I'm using
CXX=g++
CC=g++
LDFLAGS=-g -O0 -static-libgcc
CFLAGS=-O0 -Wall
CXXFLAGS=$(CFLAGS)
The flag you're looking for, in both GCC and Clang, is: -static-libstdc++
Related
I know the way to use cmake to link openmp in a cross-platform way
find_package(OpenMP REQUIRED)
link_libraries(OpenMP::OpenMP_CXX)
But I don't know how to force cmake to static link openmp, in fact, all of cmake official variable about openmp library is all dynamic.
Anyway, The non-cross-platform way to do so is:
clang++ -std=c++2a test.cpp -Iinclude -march=native -O3 -c
clang++ test.o -o test.x /usr/local/lib/libomp.a -pthread
or if you use gcc
g++-10 -std=c++2a test.cpp -Iinclude -march=native -O3 -c
g++-10 test.o -o test.x /usr/local/opt/gcc/lib/gcc/10/libgomp.a -pthread
By the way, is it a cmake defect or is there any other way to accomplish it
Not an answer but too much to fit into a comment.
I don't know anything about OpenMP other than cmake does support it:
https://cmake.org/cmake/help/latest/module/FindOpenMP.html?highlight=openmp.
I don't see any of the documentation referring to static/shared. Maybe you are correct and it only support shared libs.
Double check by asking the official make discourse:
https://discourse.cmake.org/
You could also try reading the official FindOpenMP.cmake module since this is all open source.
EDIT:
If you are correct cmake is lacking this functionality consider contributing and adding it :)
I am creating a gcc shared library having a static library dependency.
I compile the parts for static library as following:
gcc -c -m64 -O2 -fPIC -std=c99 -Wall ms*.c //there are 10 C files, no warnings
Next I create a static library with:
ar rc static_lib.a ms*.o
Next I compile the parts for my program as following:
g++ -c -m64 -O2 -fPIC -std=c++14 -Wall ab*.cpp //there are 5 C++ files, just -Wunused-variable warnings
Then I create a shared library as following:
g++ -shared -g -Wall ab*.o static_lib.a -o shared_lib.so
in the normal case, this shared_lib.so will be called by a Ruby program using a foreign function interface. There is no problem if I do it on ubuntu or mac(.dylib), but if I try this on debian stretch I get an error related to the static library as if the configurations are not set properly. If I run the application without foreign function interface, such as creating a tester and running with the cpp file main function as following:
> g++ -o library_test ab*.o static_lib.a
> ./library_test
There is no problem!
My question is what kind of configuration for creating a shared library may be missing here to not get that undesirable behaviour. Especially on debian stretch 9.5!
Or is there a way that I can understand if there is a problem in the shared library.
From the comments, you indicate the problem is with a #define. Those are preprocessor directives. Libraries are for the linker.
You might be confused because g++ does include the preprocessor phase, and might call the linker depending on the requested output. Still, g++ follows the C++ language rules.
I am trying to build my C++ application that uses boost 1.68.0. On trying to build it using cmake followed by make, I get the following linking errors,
/usr/local/bin/g++ -Wall -Wextra -g3 -std=c++14 -Wl,-rpath=/usr/local/lib -L/usr/local/lib CMakeFiles/Supervisor.dir/HeartbeatManager.cpp.o CMakeFiles/Supervisor.dir/JobReceiver.cpp.o CMakeFiles/Supervisor.dir/ResultSender.cpp.o CMakeFiles/Supervisor.dir/Supervisor.cpp.o CMakeFiles/Supervisor.dir/Process.cpp.o -o Supervisor -rdynamic -lpthread -lboost_system-mt
CMakeFiles/Supervisor.dir/HeartbeatManager.cpp.o: In function `boost::system::system_category()':
/usr/local/include/boost/system/error_code.hpp:473: undefined reference to `boost::system::detail::system_category_instance'
On switching the -std=c++14 flag with -std=c++11, the error disappears. I got the idea from this answer. I do not know why that fixes it. Now in my project I cannot use -std=c++11 flag instead of the -std=c++14 flag.
You'll have to recompile boost specifying cxxstd=14.
I am using mingw 64 bit with cygwin.
I know that if I compile using
x86_64-w64-mingw32-g++.exe -std=c++11 hello.cpp
the output .exe does not run unless the library path to libstdc++ and other libraries is specified in the Path environment variable.
An alternative is to link statically
x86_64-w64-mingw32-g++.exe -std=c++11 hello.cpp -static-libgcc -Wl,-Bstatic -lstdc++ -lpthread
Since I want a single .exe that I can easily copy on different machines, the second solution is better for me. My only problem is that, since I link statically, even for a simple helloworld program, the size of the executable rises to more than 10 Mb. So my question is: is it possible to link statically only the library parts that are actually used by the program?
The binutils linker on Windows, ld, does not support the --gc-sections argument properly, which in combination with compiler flags -ffunction-sections and -fdata-sections, allow the linker to throw away blocks of unused code.
You are straight out of luck. The only thing you can do is the usual: strip the executable (by running the strip command on it after it is linked) and compile your code optimising for size with -Os.
Keeping in mind these options do not work on Windows (which for the purpose of this answer, includes the Cygwin platform), this is generally how you can do this:
g++ -c -Os -ffunction-sections -fdata-sections some_file.cpp -o some_file.o
g++ -c -Os -ffunction-sections -fdata-sections main.cpp -o main.o
g++ -Wl,--gc-sections main.o some_file.p -o my_executable
I am trying to compile a program I wrote in C++ for an assignment that uses pthreads. I am using Eclipse in Linux, and I didn't have any problems compiling, after I added "-lpthread" to the compiler arguments (to g++, gcc and linker). However, when I was about to run and debug, Eclipse gave me an error message window "Launch failed. Binary not found."
I tried to manually compiling it with gcc and g++, with suffixes -pthread and -lpthread, and the result it similar - "gcc: –pthread: No such file or directory".
Not sure what wrong, because it does compile without problems, just doesn't produce an exe.
I believe I might need to apt-get something.
anything I should do?
How are you compiling? This should work just fine:
gcc -o foo foo.c -lpthread
g++ -pthread -ggdb -Wall -pedantic -o myexe *.cpp -lpthread should work.