How to compile cpp source to full static binary and except for: libc, libpthread, libdl, libstdc++, and libm - c++

I want to compile a binary linux to full static, But I always fail with this configuration:
CFLAGS="--static" CPPFLAGS="-I/home/alan/arm/arm-none-linux-gnueabi/libc/usr/include" LDFLAGS="-L/home/alan/arm/arm-none-linux-gnueabi/libc//usr/lib" LIBS="-lcrypt -ldl -lpthread -lm -lc -lstdc++" CC=arm-none-linux-gnueabi-gcc AR=arm-none-linux-gnueabi-ar CXX=arm-none-linux-gnueabi-g++ ./configure --host=arm-none-linux-gnueabi target=arm-none-linux-gnueabi --prefix=/home/alan/armbin/test --without-pcre --without-zlib --without-bzip2 --without-openssl --disable-ipv6 --enable-static
But I always get warning dlopen, gethostbyname, etc. If I not except libc, libm, etc to shared. I get warning approximately as below:
warning: Using 'gethostbyname' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
Thank you very much.


Use -pthread instead of -lpthread.
Source.


Your link command should look like this:
g++ objectFiles $(CFLAGS) -o executable -Wl,-Bstatic -L/path/to/static/lib1/ -ls1 -L/path/to/static/lib2 -ls2 -Wl,-Bdynamic
You only have to explicitly call the static libraries libs1.a, libs2.a . The shared system libraries you are referring to (libc.so, libpthreads.so, libm.so, libdl.so, libstdc++.so etc.) should be found implicitly by your linker and are affected by -Wl, -Bdynamic. You don't have to pass them explicitly. Try and do a
"ldd executable" to see the dynamic dependencies.

Related

How can I override shared library in LD_LIBRARY_PATH with clang++?

I'm trying to compile a shared library I wrote in C++ to use a specific version of another shared library in the current directory, however it seems to be ignoring that and it uses the (older and incompatible) .so file in my LD_LIBRARY_PATH at runtime. How would I go about overriding the .so file it uses to use my own? I also need to retain the older version for another use on the same system.
Here's my command I'm using to compile: clang++ /data/openpilot/selfdrive/df/libs/libSNPE.so -lsymphony-cpu -lsymphonypower -I/data/openpilot/phonelibs/snpe/include -std=c++14 -lstdc++ -fPIC -o d_f.so dynamic_follow.cc -shared
/data/openpilot/selfdrive/df/libs/libSNPE.so being the library I want to use.
I also tried to use the -l flag before my library file, however it returns cannot find -l/data/openpilot/selfdrive/df/libs/libSNPE.so
Confirmed to still use the library in LD_LIBRARY_PATH with this command as well: clang++ -Wl,-rpath,/data/openpilot/selfdrive/df/libs -L/data/openpilot/selfdrive/df/libs -lSNPE -lsymphony-cpu -lsymphonypower -I/data/openpilot/phonelibs/snpe/include -std=c++14 -stdlib=libc++ -fPIC -o d_f.so dynamic_follow.cc -shared

The -L flag tells where to look for libraries at link time, while LD_LIBRARY_PATH tells where to look for libraries at run-time. So whatever path you set at link-time, this will be ignored when running the executable.
You need to have LD_LIBRARY_PATH include the directory of your dynamic library at run-time for your executable to find it. So you may run your executable like this:
LD_LIBRARY_PATH=/data/openpilot/selfdrive/df/libs:"$LD_LIBRARY_PATH" ./your-exec

CMake target_link_libraries not preserving order

I am using CMake 3.8.2 (shipped with JetBrains CLion) and linking several static libraries of a custom project.
As I am required to preserve static symbols (legacy), I am including my own program parts with target_link_libraries(${TARGET} -Wl,--whole-archive ${MY_LIBRARY} -Wl,--no-whole-archive).
This works most of the time, but at some point the linker command will be like this:
/usr/bin/c++ -g CMakeFiles/my_exe.dir/my_exe.cpp.o -o my_exe libmy_other_lib.a -Wl,--whole-archive -Wl,--no-whole-archive
This is rather useless, as the library is added beforehand and then the -Wl,--whole-archive -Wl,--no-whole-archive occurs.
Note, that I need to add something like -Wl,--no-whole-archive after linking my_other_lib.a because I do not want to use this option for external dependencies.
Any thoughs on this?

Try passing these flags as a single argument to target_link_libraries, and not as a list:
target_link_libraries(${TARGET} "-Wl,--whole-archive ${MY_LIBRARY} -Wl,--no-whole-archive")

Undefined symbol in static lib linked into dynamic library

here is my issue:
At runtime my program which load shared library fail to load one, it says:
libCommunicationModule.so: undefined symbol __builtin_delete
the context:
compiler: gcc 3.4
Linux Debian 4.0 (old stuff ....)
I have a static library: libtgi_cppd.a , I don't have the source of this library.
This lib is linked into the shared library libCommunicationModule.so with these options
-Wl,-whole-archive -ltgi_cppd
I enabled -y option on __builtin_delete to check:
libtgi_cppd.a(ClientAPI_cpp.o): reference to __builtin_delete
libtgi_cppd.a(ClientInterface.o): reference to __builtin_delete
libtgi_cppd.a(ClientAPI_cpp.o): reference to __builtin_delete
I try to add to link command -lstdc++ -lgcc before and after -whole-archive, no change.
$ nm libCommunicationModule.so | grep __builtin
result is always like this:
U __builtin_delete
U __builtin_new
U __builtin_vec_new
What can I do to solve this issue?
Thank you
Full command as requiered:
g++ -Wl,-y -Wl,__builtin_delete -Wl,--trace -Wl,-rpath,/usr/local/qt/lib -shared
-Wl,-soname,libCommunicationModule-x11-Debug.so.6 -Wl,-rpath,/home/sncf/AGC_IHM/AGC/Tms/Gui/Components/CommunicationModule/x11/Debug
-o libCommunicationModule-x11-Debug.so.6.0.1 x11/Debug/Obj/CommunicationModule-Build.o x11/Debug/Obj/CommunicationModuleFilesAutoGen.o x11/Debug/Obj/CommunicationModuleParamsAutoGen.o
x11/Debug/Obj/CommunicationModule.o
x11/Debug/Obj/CommunicationModuleAutoGen.o
x11/Debug/Obj/CommDebugDlg.o
x11/Debug/Obj/moc_CommunicationModule.o x11/Debug/Obj/moc_CommDebugDlg.o
-L/usr/local/qt/lib
-L/usr/X11R6/lib -lBuildInformations-x11-Debug
-lBagsLib-x11-Debug -lConfigParamsLib-x11-Debug
-lIniLib-x11-Debug -lModuleHandling-x11-Debug
-lGenericRuntimeInfoLib-x11-Debug
-lDebugLib-x11-Debug -lTCNLib-x11-Debug
-lGUITools-x11-Debug -lQtEventsLib-x11-Debug
-lPackUnpack-x11-Debug -L/home/sncf/AGC_IHM/AGC/Tms/Gui/ProjectLib/x11
-L/home/sncf/AGC_IHM/AGC/Tms/Gui/Components/AGCTCNClientAPI/2004.09.21/posix_linux_i586/lib
-lqt-mt -lXext -lX11 -lm -lpthread -Wl,-whole-archive -ltgi_cppd -lstdc++ -lgcc

You linked against a library which was compiled/linked by another compiler/linker version. What you need is to link against a library which was compiled and linked by the same compiler/linker as used by yourself, or you have to make sure, that the libraries are at least binary compatible.

Execute command ldd and it will list out all shared libraries using by your program.
Check the environment variable LIBPATH /LD_PATH in your execution environment. And make sure all those libraries are present in that path
Make sure all library files have sufficient permission

how to do static linking of libwinpthread-1.dll in mingw?

I use mingw from here: http://sourceforge.net/projects/mingwbuilds/files/host-windows/releases/4.7.2/32-bit/threads-posix/sjlj/x32-4.7.2-release-posix-sjlj-rev2.7z/download
And I've sucessfully managed to link statically libstdc++-6.dll and libgcc_s_sjlj-1.dll by using -static-libgcc -static-libstdc++ parameters, but I cannot find a command for doing the same with libwinpthread-1.dll.

If your toolchain includes the static winpthreads, adding the option
-static
Will pull in static versions of all libraries it can.
Alternatively, you can remove libwinpthread.dll.a and the DLL itself from the toolchain directories. This might mess up programs linking with libstdc++ and libgcc DLLs though, so be careful.
A third option is to use -Wl,-Bdynamic and -Wl,-Bstatic to select which version you want linked in (which is what -static internally does when ld is called). An example:
gcc -o someexec someobject.o -Wl,-Bdynamic -lsomelibIwantshared -Wl,-Bstatic -lsomelibIwantstatic
If you run your link command with -v added, you should see these options appearing in the ld/collect2 invocation when you use -static-libgcc and -static-libstdc++.

Try this:
-static-libgcc -static-libstdc++ -Wl,-Bstatic -lstdc++ -lpthread -Wl,-Bdynamic
Notice the -lstdc++ before -lpthread. It worked for me.
Make sure to add this to the very end of your g++ command line.

You should probably check command line options documentation for GCC.
These's no '-static-something' command, only standard libraries (libgcc and libstdc++) can be set to static linking with one command. For other libraries, you first switch to static linking with "-static" and then list the libraries to include with separate commands, ie "-lpthread".

To statically link winpthread even if threading isn't used in the program, pass the -Bstatic and --whole-archive parameters to the linker:
g++ -o hello.exe hello.cpp -Wl,-Bstatic,--whole-archive -lwinpthread -Wl,--no-whole-archive
Note the following:
The "whole archive" option should be disabled immediately afterwards.
You don't need to do this hack if your program actually uses symbols from the library (i.e. you use <thread> from C++11), in which case the library won't get dropped when you statically link it.
This hack is intended for MinGW-w64, to fix the libwinpthread-1.dll dependencies.

For anyone working in CMake, this solution is readily implemented in your CMakeLists.txt file as follows...
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -static")

Apparently, CMake does some weird stuff with how the -Wl compiler flags are handled, making the -Wl,-Bstatic -lstdc++ -lwinpthread -Wl,-Bdynamic solution not work, with only two other options seemingly left: the bad compiler flag -static and the ugly compiler flag -Wl,--whole-archive.
Meanwhile, the good option that actually works in CMake, yet seems rather undocumented, is to directly use the linker flags. Hence, in CMake, this seems to be the best way to statically link to all the mingw-w64 C++ dependencies:
target_link_libraries (MyVeryAwesomeApp -static gcc stdc++ winpthread -dynamic)
It should be noted that even if there isn't a library explicitly following -dynamic, it should still be applied in order to ensure that the standard, implicitly linked libraries get linked correctly.

I circumvented this problem by using win32 variant of the mingw toolchain instead of the posix variant. With the win32 variant, -static-libgcc -static-libstdc++ is sufficient for an independent build.

If you are using toolchains from MSys2 (tested with gcc version 12) ,the only way to use winpthread statically is standard -static (forces all library to be static) or simply delete/rename the libwinpthread.dll.a && libpthread.dll.a imp libs.
Other methods like "Bstatic", "-l:libwinpthread.a" will no longer work (due to dependency hell, especially in CMake). The one with whole archive still works but it overrides the program properties.
You may also want static link libgcc and libstdc++ if the dependency comes from them.

Just link with -l:libwinpthread.a

Just add -static to your CFLAGS.
For example: ./configure CFLAGS="-static".
This will link all static libraries to your executable file.

Linking a static library into Boost Python (shared library) - Import Error

I am building a Boost Python module (.so shared library file) which depends on another external library (STXXL)
While I can build and import the example Boost Python modules, I run into problems when STXXL is thrown into the mix. Specifically when running import fast_parts in python
I get ImportError: ./fast_parts.so: undefined symbol: _ZN5stxxl10ran32StateE
This says to me that the STXXL library isn't being linked, but I am not sure how that could be as I am linking against it and the linker isn't giving me any errors. It's worth noting I can successfully build and run standalone programs using STXXL and as far as I know the libraries are stored in a .a archive in the lib directory shown below. I have reduced my Makefile down to a single command as follows:
g++ -I/home/zenna/Downloads/stxxl-1.3.0/include -include stxxl/bits/defines.h -I/home/zenna/local/include -I/usr/include/python2.6 -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -O3 -Wall -g -DFOO=BAR -pthread -L/home/zenna/Downloads/stxxl-1.3.0/lib/ -lstxxl -L/home/zenna/local/lib/ -lboost_python -lpython2.6 -fPIC -shared -o fast_parts.so partition.cpp
Any advice?

I'm assuming Linux, please comment if this is incorrect. What does the ldd output for libfast_parts.so look like? Does it indicate libstxxl.so is not found?
You might need to add /home/zenna/Downloads/stxxl-1.3.0/lib/ in your LD_LIBRARY_PATH or the rpath for libfast_parts.so.
-Wl,-rpath,/home/zenna/Downloads/stxxl-1.3.0/lib -L/home/zenna/Downloads/stxxl-1.3.0/lib -lstxxl