I'm trying to compile llvm-ar (and only that) from LLVM statically because I need a static ar implementation for another purpose. AFAICS the official LLVM building documentation doesn't discuss this usage, only the option to build with shared libs, which is disabled by default anyway. Adding -static to CLAGS or the CMake option LLVM CFLAGS doesn't change the build process at all.
This is the build process I'm running right now:
cmake -DLLVM_ENABLE_PROJECTS=llvm-ar -G "Unix Makefiles" ../llvm
make -j3 llvm-ar
which then builds a dynamic llvm-ar:
$ ldd bin/llvm-ar
linux-vdso.so.1 (0x00007fff46154000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007faa84536000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007faa84319000)
libtinfo.so.5 => /lib/x86_64-linux-gnu/libtinfo.so.5 (0x00007faa840ef000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007faa83d66000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007faa839c8000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007faa837b0000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007faa833bf000)
/lib64/ld-linux-x86-64.so.2 (0x00007faa87163000)
How can I cause this target to be compiled statically? I'd also like to build with musl-gcc instead of the system default.
Related
I am trying to build a simple program against a library, which itself depends on librt. The library compiles just fine and the -lrt flag is used there. The program also builds fine on amd64 using cmake - but on arm64, it fails. This is not cross-compilation, but directly building it on the target. I'm using a normal cmake build system (cmake ..; make).
The exact same build system can also compile a different program, which uses the same library, but not the same functions from it.
Here is the build error:
[100%] Linking C executable mrun-talker
/usr/lib/gcc/aarch64-linux-gnu/7/../../../../lib/libsec-common.so: undefined reference to `shm_open'
/usr/lib/gcc/aarch64-linux-gnu/7/../../../../lib/libsec-common.so: undefined reference to `shm_unlink'
And here is the linker command:
/usr/bin/cc CMakeFiles/sec-talker.dir/main.c.o -o sec-talker -lsec-common -lsec-rosc -lsec-api -ltert -lgcov -lm -lrt -lpthread
The linker command does contain the -lrt flag at the end of the command and the lrt.so is available on the target.
Is there a chance that although the library compiles just fine, it does not properly link and causes this error later when I try to use it?
Full cmake-file:
get_filename_component(ProjectId ${CMAKE_CURRENT_SOURCE_DIR} NAME)
string(REPLACE " " "_" ProjectId ${ProjectId})
project(${ProjectId})
set(ExecName ${ProjectId})
enable_language(C)
find_package(Threads)
add_executable(${ExecName} main.c)
target_link_libraries(
${ExecName}
# sec libraries
sec-common
sec-rosc
sec-api
tert
# system libraries
gcov
m
Threads::Threads
rt
)
link_directories("/usr/local/lib")
install(TARGETS ${ExecName})
/edit
I used ldd to check the linking of the libsec-common. Here is the result of the (working) amd64 version:
# ldd /usr/lib/libsec-common.so
linux-vdso.so.1 (0x00007fff7e922000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007ffa350ef000)
/lib64/ld-linux-x86-64.so.2 (0x00007ffa356ec000)
And of the (not-working) arm64 version.
# ldd /usr/lib/libsec-common.so
linux-vdso.so.1 (0x0000ffffb2dc6000)
libc.so.6 => /lib/aarch64-linux-gnu/libc.so.6 (0x0000ffffb2c26000)
/lib/ld-linux-aarch64.so.1 (0x0000ffffb2d9b000)
I don't see an issue here tbh.
The issue here was that the dependency itself did not correctly link it's dependency.
Using target_link_libraries in my CMakeLists.txt file results in only some of the shared-object library dependencies being set in the built library.
In my CMakeLists.txt file I have this:
set(STIREN_LIBS)
list(APPEND STIREN_LIBS
/usr/lib/x86_64-linux-gnu/libcairo.so
/usr/lib/x86_64-linux-gnu/libboost_filesystem.so
/usr/lib/x86_64-linux-gnu/libboost_regex.so
/usr/lib/x86_64-linux-gnu/libicuuc.so
/usr/lib/x86_64-linux-gnu/libproj.so.12
/usr/lib/x86_64-linux-gnu/libharfbuzz.so
/usr/lib/x86_64-linux-gnu/libxml2.so
)
If I call target_link_libraries on that, as follows:
target_link_libraries(${PROJECT_NAME} PRIVATE ${STIREN_LIBS})
I get this as the result of objdump -p
Dynamic Section:
NEEDED libcairo.so.2
NEEDED libboost_filesystem.so.1.65.1
NEEDED libboost_regex.so.1.65.1
NEEDED libproj.so.12
NEEDED libxml2.so.2
NEEDED libstdc++.so.6
NEEDED libm.so.6
NEEDED libgcc_s.so.1
NEEDED libc.so.6
NEEDED ld-linux-x86-64.so.2
SONAME libstiren.so
It is missing the dependencies for libicuuc and lifharfbuzz. I confirm that those file paths are valid.
If I omit the target_link_libraries, I get this in the output of objdump -p
Dynamic Section:
NEEDED libstdc++.so.6
NEEDED libm.so.6
NEEDED libgcc_s.so.1
NEEDED libc.so.6
NEEDED ld-linux-x86-64.so.2
SONAME libstiren.so
So why is it that only some dependencies making it through?
I have created an application where it uses libssl which apparently uses libcrypto. I have kept these libraries at a user-defined location /path/to/xyz/lib/
---------------------------------------------------------------------------------------------------------------------------------
I have written a CMake for the application which links the libraries as follows:
set(GCC_LINK_FLAGS "-L/path/to/xyz/lib -lcurl -lpthread -lcrypto -lssl //other libs")
add_executable(Foo ${APP_SOURCE_FILES})
target_link_libraries(Foo ${GCC_LINK_FLAGS})
The CMake didnot give any error and created the Makefile which creates the executable.
---------------------------------------------------------------------------------------------------------------------------------
But When I run the executable. it throws the below error
./Foo: error while loading shared libraries: libcrypto.so.3: cannot open shared object file: No such file or directory
I have checked the dynamic linking of libssl.so as follows and found the libcrypto isn't linked...
[root#localhost build]# ldd /path/to/xyz/lib/libssl.so.3
linux-vdso.so.1 => (0x00007fffa5fa7000)
libcrypto.so.3 => not found
libdl.so.2 => /lib64/libdl.so.2 (0x00007f17ea772000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f17ea556000)
libc.so.6 => /lib64/libc.so.6 (0x00007f17ea193000)
/lib64/ld-linux-x86-64.so.2 (0x0000563b0856f000)
I have checked the /path/to/xyz/lib/pkgconfig/libssl.pc file and found this suspicious for this error
prefix=/path/to/xyz/lib/
exec_prefix=${prefix}
libdir=${exec_prefix}/lib
includedir=${prefix}/include
Name: OpenSSL-libssl
Description: Secure Sockets Layer and cryptography libraries
Version: 3.0.0-dev
Requires.private: libcrypto
Libs: -L${libdir} -lssl
Cflags: -I${includedir}
QUESTION
What does Requires.private: libcrypto do?
And how to solve this error?
--------------------------------------------------------------EDIT--------------------------------------------------------------
I have Done following edits in the cmake file
set(CMAKE_SKIP_BUILD_RPATH FALSE)
set(CMAKE_BUILD_WITH_INSTALL_RPATH FALSE)
set(CMAKE_INSTALL_RPATH "/path/to/xyz/lib")
set(CMAKE_INSTALL_RPATH_USE_LINK_PATH TRUE)
add_executable(SpeechToText ${APP_SOURCE_FILES})
target_link_libraries(Foo ${GCC_LINK_FLAGS})
install (TARGETS Foo RUNTIME DESTINATION /path/to/project/directory)
I am getting segmentation fault by this change.
Install the project...
-- Install configuration: ""
-- Installing: /path/to/project/directory/Foo
-- Set runtime path of "/path/to/project/directory/Foo" to "/path/to/xyz/lib"
[root#localhost build]# ../Foo
Segmentation fault (core dumped)
I'm working on a c++ project witch use mongodb as database.
I want to static link the mongodb driver.
I use this command to build the executable binary.
g++ -o ox one.cpp -pthread -Wall -std=c++11 \
-I /opt/mongo-cxx-driver/include/bsoncxx/v_noabi/ \
-I /opt/mongo-cxx-driver/include/mongocxx/v_noabi/ \
-L /opt/mongo-cxx-driver/lib/ \
-L /opt/mongo-c-driver/lib/ \
-Wl,-Bstatic -lmongocxx -lbsoncxx -lmongoc-1.0 -lbson-1.0 \
-Wl,-Bdynamic -lgcc_s -lstdc++ -lcrypto -lssl -lrt
ldd ox reports that mongodb driver has been static linked
linux-vdso.so.1 => (0x00007ffd1a99d000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f7f8e4e0000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f7f8e15e000)
libcrypto.so.1.0.0 => /lib/x86_64-linux-gnu/libcrypto.so.1.0.0 (0x00007f7f8dd19000)
libssl.so.1.0.0 => /lib/x86_64-linux-gnu/libssl.so.1.0.0 (0x00007f7f8dab0000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f7f8d8a8000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f7f8d689000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f7f8d2bf000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f7f8cfb7000)
/lib64/ld-linux-x86-64.so.2 (0x000055fc81736000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f7f8cdb2000)
Now, I can simply copy the ox file to another computer (same os, same version) to use it.
But, My question is that, How to write rule in CMakeList.txt, to tell cmake which libraries I want to static link, which libraries I want to dynamic link ?
If you wanna dynamically link a library, you must have a .so version of that library; likewise, if you wanna statically link a library, you must have a .a version of that library. Of course, this is for Linux like system
I'm trying to emulate a firmware with qemu, but I'm getting an error while trying to execute it.
First of all I extracted the firmware filesystem to a folder, and copied de qemu-mipsel file to it:
bin cdrom dev etc home init lib linuxrc mnt opt proc qemu-mipsel root sbin sys tango tmp udev usr var
Then I executed the emulator with chroot:
chroot . ./qemu-mipsel ./bin/ls
And I get the following error:
chroot: failed to run command `./qemu-mipsel': No such file or directory
Googling the error I found that it means that qemu depends on libraries not included in the chroot environment so I searched for them:
linux-vdso.so.1 => (0x00007fffe79ff000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007fcd9da57000)
libgthread-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgthread-2.0.so.0 (0x00007fcd9d855000)
libglib-2.0.so.0 => /lib/x86_64-linux-gnu/libglib-2.0.so.0 (0x00007fcd9d55d000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fcd9d2db000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fcd9d0be000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fcd9cd34000)
/lib64/ld-linux-x86-64.so.2 (0x00007fcda007a000)
libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3 (0x00007fcd9caf7000)
And some libraries are missing in ./lib/:
linux-vdso.so.1
libgthread-2.0.so.0
libglib-2.0.so.0
/lib64/ld-linux-x86-64.so.2
libpcre.so.3
How could I solve this problem? Can I create a symbolic link to the system library or should I copy them? Also linux-vdso.so.1 is not present on the system, where could I get it? Regards.
linux-vdso.so.1 is in reality the kernel. The other files, you get them from your GNU/Linux distribution of choice (e.g. Debian, from the source packages eglibc, pcre3 and glib2.0). You must indeed copy them into the chroot. For /lib64/ld-linux-x86-64.so.2 the pathname must be exact, as that path is hard-coded into the binary.
It seems you’re running Debian already, from the multiarch’d paths, which is good, because you’ll need to distinguish between host and target libraries.
Alternatively, you can compile and link qemu-mipsel statically.