Using a vendor provided cross-compiling toolchain (apparently an OpenEmbedded derivative), I'm unable to embed the absolute path to third-party (open source, compiled in house)libraries. With the following gcc command line:
arm-linux-gcc test_connect_send.o gprs_connect.o \
/package/host/myvendor.com/API-R-2.0.0/Release/Libraries/libgprs_stuff.so \
/package/host/myvendor.com/API-R-2.0.0/Release/Libraries/libpower_supply_stuff.so \
/package/host/myvendor.com/API-R-2.0.0/Release/Libraries/libgsm_stuff.so \
/package/host/myvendor.com/API-R-2.0.0/Release/Libraries/libtcp_stuff.so \
/package/host/aspl.es/vortex-1.1.0/lib/libvortex-1.1.so \
/package/host/aspl.es/axl-0.5.6/lib/libaxl.so.0 -o test_connect_send
objdump says:
Dynamic Section:
NEEDED /package/host/myvendor.com/API-R-2.0.0/Release/Libraries/libgprs_stuff.so
NEEDED /package/host/myvendor.com/API-R-2.0.0/Release/Libraries/libpower_supply_stuff.so
NEEDED /package/host/myvendor.com/API-R-2.0.0/Release/Libraries/libgsm_stuff.so
NEEDED /package/host/myvendor.com/API-R-2.0.0/Release/Libraries/libtcp_stuff.so
NEEDED libvortex-1.1.so.0
NEEDED libaxl.so.0
NEEDED libgcc_s.so.1
NEEDED libc.so.6
Notice how my vendor's libraries do have their full path, while aspl's don't. Also, notice how the name embedded is different from the one I specified on the command line. I'd like to know why (who is messing with my paths), and how to solve it.
p.s.: I know about RPATH, that's not the answer I'm looking for
My guess would be that the vendor supplied libs set the SONAME to the full installed path.
arm-linux-gcc -print-file-name does not show anything suprising:
arm-linux-gcc -print-file-name=/package/host/aspl.es/axl-0.5.6/lib/libaxl.so.0.0.0
/package/host/aspl.es/axl-0.5.6/lib/libaxl.so.0.0.0
arm-linux-gcc -print-file-name=/package/host/aspl.es/axl-0.5.6/lib/libaxl.so.0.0
/package/host/aspl.es/axl-0.5.6/lib/libaxl.so.0.0
arm-linux-gcc -print-file-name=/package/host/aspl.es/axl-0.5.6/lib/libaxl.so.0
/package/host/aspl.es/axl-0.5.6/lib/libaxl.so.0
arm-linux-gcc -print-file-name=/package/host/aspl.es/axl-0.5.6/lib/libaxl.so
/package/host/aspl.es/axl-0.5.6/lib/libaxl.so
The resulting binary does not run without LD_LIBRARY_PATH defined, nor does it have a DT_RPATH (although that might certainly help, suggestions?)
I don't want to rely on /etc/ld.so.conf being properly set, and thus I want absolute paths everywhere.
Note that suggestions might well point to the compilation of the third-party libraries, which as of now are compiled with:
make distclean; LDFLAGS=-L/package/host/myvendor.com/arm9-linux-toolchain-2.1/prefix/arm-linux/lib CC=/package/host/myvendor.com/arm9-linux-toolchain-2.1/prefix/bin/arm-linux-gcc ~/wd/sources/contrib/axl/configure --prefix=/shared/syst/arm9-linux-abtrack/package/host/aspl.es/axl-0.5.6 --host=armv4tl-unknown-linux-gnu --disable-axl-knife --disable-axl-babel --disable-axl-log --disable-axl-test && make
make distclean; AXL_LIBS="-L/shared/syst/arm9-linux-abtrack/package/host/aspl.es/axl-0.5.6/lib/ -laxl -lm" AXL_CFLAGS=-I/shared/syst/arm9-linux-abtrack/package/host/aspl.es/axl-0.5.6/include/axl CC=/package/host/myvendor.com/arm9-linux-toolchain-2.1/prefix/bin/arm-linux-gcc LDFLAGS="-L/package/host/myvendor.com/arm9-linux-toolchain-2.1/prefix/arm-linux/lib" ~/wd/sources/contrib/vortex/configure --prefix=/shared/syst/arm9-linux-abtrack/package/host/aspl.es/vortex-1.1.0 --disable-http-support --disable-pull-support --disable-tunnel-support --disable-xml-rpc-support-gen --disable-xml-rpc-support --disable-sasl-support --disable-vortex-log --disable-vortex-client --host=armv4tl-unknown-linux-gnu && make
Any autofoo tips for embedding --prefix in compiled libraries?
This is an old question, but I thought I'd add a possible answer anyways.
Just based on the info you've given, could it be that the full path names aren't included for aspl because the aspl libraries you've specified are soft links? If you do a long list on, for instance, /package/host/aspl.es/vortex-1.1.0/lib/libvortex-1.1.so it will show that it's a link to libvortex-1.1.so.0 (with no full pathname).
So, if you still want to embedded the full path, then you need to use the full path to the actual library, not the linked library.
Related
Looking around on the net I have seen a lot of code like this:
include(FindPkgConfig)
pkg_search_module(SDL2 REQUIRED sdl2)
target_include_directories(app SYSTEM PUBLIC ${SDL2_INCLUDE_DIRS})
target_link_libraries(app ${SDL2_LIBRARIES})
However that seems to be the wrong way about doing it, as it only uses the include directories and libraries, but ignored defines, library paths and other flags that might be returned by pkg-config.
What would be the correct way to do this and ensure that all compile and link flags returned by pkg-config are used by the compiled app? And is there a single command to accomplish this, i.e. something like target_use(app SDL2)?
ref:
include()
FindPkgConfig
First of, the call:
include(FindPkgConfig)
should be replaced with:
find_package(PkgConfig)
The find_package() call is more flexible and allows options such as REQUIRED, that do things automatically that one would have to do manually with include().
Secondly, manually calling pkg-config should be avoid when possible. CMake comes with a rich set of package definitions, found in Linux under /usr/share/cmake-3.0/Modules/Find*cmake. These provide more options and choice for the user than a raw call to pkg_search_module().
As for the mentioned hypothetical target_use() command, CMake already has that built-in in a way with PUBLIC|PRIVATE|INTERFACE. A call like target_include_directories(mytarget PUBLIC ...) will cause the include directories to be automatically used in every target that uses mytarget, e.g. target_link_libraries(myapp mytarget). However this mechanism seems to be only for libraries created within the CMakeLists.txt file and does not work for libraries acquired with pkg_search_module(). The call add_library(bar SHARED IMPORTED) might be used for that, but I haven't yet looked into that.
As for the main question, this here works in most cases:
find_package(PkgConfig REQUIRED)
pkg_check_modules(SDL2 REQUIRED sdl2)
...
target_link_libraries(testapp ${SDL2_LIBRARIES})
target_include_directories(testapp PUBLIC ${SDL2_INCLUDE_DIRS})
target_compile_options(testapp PUBLIC ${SDL2_CFLAGS_OTHER})
The SDL2_CFLAGS_OTHER contains defines and other flags necessary for a successful compile. The flags SDL2_LIBRARY_DIRS and SDL2_LDFLAGS_OTHER are however still ignored, no idea how often that would become a problem.
More documentation here http://www.cmake.org/cmake/help/latest/module/FindPkgConfig.html
If you're using cmake and pkg-config in a pretty normal way, this solution works.
If, however, you have a library that exists in some development directory (such as /home/me/hack/lib), then using other methods seen here fail to configure the linker paths. Libraries that are not found under the typical install locations would result in linker errors, like /usr/bin/ld: cannot find -lmy-hacking-library-1.0. This solution fixes the linker error for that case.
Another issue could be that the pkg-config files are not installed in the normal place, and the pkg-config paths for the project need to be added using the PKG_CONFIG_PATH environment variable while cmake is running (see other Stack Overflow questions regarding this). This solution also works well when you use the correct pkg-config path.
Using IMPORTED_TARGET is key to solving the issues above. This solution is an improvement on this earlier answer and boils down to this final version of a working CMakeLists.txt:
cmake_minimum_required(VERSION 3.14)
project(ya-project C)
# the `pkg_check_modules` function is created with this call
find_package(PkgConfig REQUIRED)
# these calls create special `PkgConfig::<MODULE>` variables
pkg_check_modules(MY_PKG REQUIRED IMPORTED_TARGET any-package)
pkg_check_modules(YOUR_PKG REQUIRED IMPORTED_TARGET ya-package)
add_executable(program-name file.c ya.c)
target_link_libraries(program-name PUBLIC
PkgConfig::MY_PKG
PkgConfig::YOUR_PKG)
Note that target_link_libraries does more than change the linker commands. It also propagates other PUBLIC properties of specified targets like compiler flags, compiler defines, include paths, etc., so, use the PUBLIC keyword with caution.
It's rare that one would only need to link with SDL2. The currently popular answer uses pkg_search_module() which checks for given modules and uses the first working one.
It is more likely that you want to link with SDL2 and SDL2_Mixer and SDL2_TTF, etc... pkg_check_modules() checks for all the given modules.
# sdl2 linking variables
find_package(PkgConfig REQUIRED)
pkg_check_modules(SDL2 REQUIRED sdl2 SDL2_ttf SDL2_mixer SDL2_image)
# your app
file(GLOB SRC "my_app/*.c")
add_executable(my_app ${SRC})
target_link_libraries(my_app ${SDL2_LIBRARIES})
target_include_directories(my_app PUBLIC ${SDL2_INCLUDE_DIRS})
target_compile_options(my_app PUBLIC ${SDL2_CFLAGS_OTHER})
Disclaimer: I would have simply commented on Grumbel's self answer if I had enough street creds with stackoverflow.
Most of the available answers fail to configure the headers for the pkg-config library. After meditating on the Documentation for FindPkgConfig I came up with a solution that provides those also:
include(FindPkgConfig)
if(NOT PKG_CONFIG_FOUND)
message(FATAL_ERROR "pkg-config not found!" )
endif()
pkg_check_modules(<some-lib> REQUIRED IMPORTED_TARGET <some-lib>)
target_link_libraries(<my-target> PkgConfig::<some-lib>)
(Substitute your target in place of <my-target> and whatever library in place of <some-lib>, accordingly.)
The IMPORTED_TARGET option seems to be key and makes everything then available under the PkgConfig:: namespace. This was all that was required and also all that should be required.
There is no such command as target_use. But I know several projects that have written such a command for their internal use. But every project want to pass additional flags or defines, thus it does not make sense to have it in general CMake. Another reason not to have it are C++ templated libraries like Eigen, there is no library but you only have a bunch of include files.
The described way is often correct. It might differ for some libraries, then you'll have to add _LDFLAGS or _CFLAGS. One more reason for not having target_use. If it does not work for you, ask a new question specific about SDL2 or whatever library you want use.
If you are looking to add definitions from the library as well, the add_definitions instruction is there for that. Documentation can be found here, along with more ways to add compiler flags.
The following code snippet uses this instruction to add GTKGL to the project:
pkg_check_modules(GTKGL REQUIRED gtkglext-1.0)
include_directories(${GTKGL_INCLUDE_DIRS})
link_directories(${GTKGL_LIBRARY_DIRS})
add_definitions(${GTKGL_CFLAGS_OTHER})
set(LIBS ${LIBS} ${GTKGL_LIBRARIES})
target_link_libraries([insert name of program] ${LIBS})
I'm cross compiling on Windows 7 and I use this compiler:
gcc-linaro-arm-linux-gnueabihf-4.7-2013.03\bin\arm-linux-gnueabihf-g++.exe
I want to use libcurl for some HTTP requests but when I link using -libcurl I get the infamous message that the linker couldn't find that library. I tried searching on the internet for the correct library for this architecture (ARMHF) but I can't find anything. Or maybe I did find it but I'm doing things wrong? My linking call is long but here it is:
This is the one that works, if I add -libcurl or anything related it breaks...
C:\vde\toolchains\windows\vos2\gcc-linaro-arm-linux-gnueabihf-4.7-2013.03\bin\arm-linux-gnueabihf-g++.exe -o out\RefApp -Wl,-rpath=C:\vde\SDKs\vos2\vos2-sdk-winx86-release-31010800\vos2\usr\lib -Wl,-r
path=C:\vde\SDKs\vos2\vos2-sdk-winx86-release-31010800\vos2\usr\local\lib -Wl,-rpath=C:\vde\SDKs\vos2\vos2-sdk-winx86-release-31010800\vos2\lib -Wl,-rpath=C:\vde\SDKs\vos2\vos2-sdk-winx86-release-3101
0800\vos2\usr\local\lib\svcmgr C:\desarrollo\corvet\out\corvet.a -LC:\desarrollo\RefApp\lib -LC:\vde\SDKs\vos2\vos2-sdk-winx86-release-31010800\vos2\usr\local\lib -LC:\vde\SDKs\vos2\vos2-sdk-winx86-re
lease-31010800\vos2\lib -LC:\vde\SDKs\vos2\vos2-sdk-winx86-release-31010800\vos2\usr\local\lib\svcmgr -LC:\vde\ADKs\adk-full-4.6.5-610\vos2\lib -L -LC:\desarrollo\corvet\out -lrt -llog -lvfiguiprt -l
vfiipc -lTLV_Util -lpthread -lvfiplatforminfo -lsvc_utility -lvfibuzzer -lsvc_powermngt -lsvc_led -lvfisysinfo -lvfisysbar -lsqlite -lexpat -linf -lcom -levt -ltecclient -lmsrclient -lEMV_CT_Link -lEM
V_CT_Client -lEMV_CTLS_Link -lEMV_CTLS_Client -lNFC_Framework -lNFC_Client -lsvc_tms -lUtils -lseccmd-static -lsvc_sound -lccp -lcrypto -lsec -lseccmd-static -lsecins -lvfisvc -lvfisyspm -lvfimac -lvf
isec -lAdkCapX
I also tried downloading some libcurl libraries I found on debian page and that were supposedly for ARMHF, put them in some folder and used -L(routetofolder) but that didn't work either.
Hope you guys can help me out.
Thanks!
Well, libcurl is there in what you get from the vendor (if you look at /usr/lib you will find it there). It's a problem with your linking.
You might want to try looking at how dynamic libraries dependencies are resolved at linking and later at runtime on linux systems. It will also help you understand what may be happening on vos2 platform when you will try using your own dynamic libraries that may have conflicting names and linker can resolve them to something existing on the same device but at a location that you might not have permissions to read, because it belongs to different usrXX or sysXX.
Reading /etc/ld.so.conf from the device will help you understand the locations and search order done by dynamic linker. You can get the file from the device or simply find it in OS.rfsbundle (look in skeletonfs) and set your linking options right. I think it's not normally distributed with sysroot by the vendor but you can manually add it.
I want to use functions in the header files gmp.h and mpfr.h, which are in the file /opt/local/include.
But when I run gcc with -v, all of the search paths are something like /Application/Xcode.app/Contents/etc.
I have tried adding LD_LIBRARY_PATH="/opt/local/include" to .bash_profile but it doesn't work. The compiler either tells me that 'gmp.h' file not found, or Undefined symbols for architecture x86_64.
What should I do?
Converting comments into an answer.
You need to add -I/opt/local/include to compile commands (to specify where the headers are) and -L/opt/local/lib and -lgmp and -lmpfr (possibly in the reverse order — MPFR before GMP) to link commands.
That works! Would you mind explaining a little bit the logic behind this? For example if I had another header file header.h I need, how should I include it?
You include it with #include "header.h". You compile the code with -I/directory/containing/header to find the header. You specify where the library (libheader.a or libheader.dylib, since you seem to be on macOS) is too, with -L/directory/containing/lib and -lheader — or whatever is appropriate.
The -I tells the preprocessor to look in the named directory for header files, so it looks for /directory/containing/header/header.h, for example.
The -L tells the linker where to find libraries (so it looks for /directory/containing/lib/libheader.dylib etc).
The -lheader tells the linker to look for libheader.a or libheader.dylib (or local equivalents) for the libraries.
Except for the use of .dylib vs .so vs .dll vs … (and .a vs .lib vs …), the same principles apply to other systems too.
This is probably a duplicate.
I'm trying to write a simple syntax checker for C code using the frontend available in libclang. Due to deployment concerns, I need to be able to statically link all the libraries in libclang, and not pass around the .so file that has all the libraries.
I'm building clang/llvm from source, and in llvm/Release+Asserts/lib I have a bunch of .a files that I think I should be able to use, but it never seems to work (the linker spews out thousands of errors about missing symbols). However, when I compile it using the libclang.so also present in that directory as follows:
clang main.c -o bin/dlc -I../llvm/tools/clang/include -L../llvm/Release+Asserts/lib/ -lclang
Everything seems to work well.
What is the minimum set of .a files I need to include to make this work? I've tried including absolutely all of the .a files in the build output directory, with them provided to clang/gcc in different orders, without any success. I only need the functions mentioned in libclang's Index.h, but there don't seem to be any resources or documentation on what the various libclang*.a files are for. It would be very helpful to know which files libclang.so pulls in.
The following is supposed to work, as long the whole project has all static libraries (I counted 116 in my Release/lib directory).
clang main.c -o bin/dlc -I../llvm/tools/clang/include ../llvm/Release/lib/*.a
[edit: clang main.c -o bin/dlc -I../llvm/tools/clang/include ../llvm/Release/lib/libclang.a ../llvm/Release/lib/*.a]
Note that the output binary is not static, so you don't need any -static flag for gcc or ld, if you're using this syntax.
If that doesn't work you might need to list the libraries in order: if some library requires a function available in another library, then it may be necessary to list it first in the command line. See comments about link order at:
http://gcc.gnu.org/onlinedocs/gcc-4.7.2/gcc/Link-Options.html#Link-Options
In my SConscript I have the following line:
Program("xtest", Split("main.cpp"), LIBS="mylib fltk Xft Xinerama Xext X11 m")
How do I get scons to use mylib.a instead of mylib.so, while linking dynamically with the other libraries?
EDIT: Looking to use as few platform specific hacks as possible.
Passing the full filepath wrapped in a File node will force static linking. For example:
lib = File('/usr/lib/libfoo.a')
Program('bar', 'main.c', LIBS = [lib])
Will produce the following linker command line
g++ -o bar main.o /usr/lib/libfoo.a
Notice how the "-l" flag is not passed to the linker for this LIBS entry. This effectively forces static linking. The alternative is to modify LINKFLAGS to get what you want with the caveat that you are bypassing the library dependency scanner -- the status of the library will not be checked for rebuilds.
To make this platform independent you append the env['SHLIBSUFFIX'] onto the library you want to use. env['SHLIBSUFFIX'] gives you this environments suffix for shared libraries.
You also have the ['SHLIBPREFIX'], ['LIBPREFIX'], ['LIBSUFFIX'] and ['PROGSUFFIX'], all useful for situations like this.
Edit:
I obviously haven't made myself understood, so I will clarify.
The return value of these lookups are strings to the pre/suffixes that platform uses. In that way you can refer to the file you need on each platform. Note that you cannot use it as a pure string, it has to be embedded as a file node as BennyG suggests. Working with nodes are anyway the best solution as file nodes are much more versatile than a string.
Hope this helps.