Cross compiling an executable for an embedded system with CMake requires me to manually add link options to link libc, libgcc and whatnot. However using target_link_options for that results in a linker call where all those additional link options are added in front of all the object files generated from my actual code. I believe that this is the wrong linking order and it causes "duplicate symbol errors" whenever I try to overwrite weak symbols from the standard library (e.g. __cxa_pure_virtual).
Here is an exemplar of the output I get from the linking stage
"/usr/bin/ld.lld"
--gc-sections
/usr/arm-none-eabi/lib/crt0.o
/usr/lib/gcc/arm-none-eabi/10.1.0/thumb/v7e-m+fp/hard/crti.o
/usr/lib/gcc/arm-none-eabi/10.1.0/thumb/v7e-m+fp/hard/crtbegin.o
/usr/lib/gcc/arm-none-eabi/10.1.0/thumb/v7e-m+fp/hard/crtn.o
/usr/lib/gcc/arm-none-eabi/10.1.0/thumb/v7e-m+fp/hard/crtend.o
--start-group -lstdc++_nano -lm -lgcc -lc_nano --end-group
my.obj ///< Shoudln't object files and application libs be linked first?
libmylib.a
-Bstatic
-L/usr/lib/clang/10.0.0/lib/baremetal
-L/usr/arm-none-eabi/lib/thumb/v7e-m+fp/hard/
-L/usr/lib/gcc/arm-none-eabi/10.1.0/thumb/v7e-m+fp/hard/
-T ldscript.ld
-o myelf
Is there any way to solve this in CMake?
target_link_options specifies options to the linker - and typically options are specified before anything else. Use target_link_libraries to link with libraries.
Related
In CMake, is it possible to programmatically retrieve the complete list of linker flags that will be used for a given target? The only way I can see to do this is to inspect the link.txt file in the target's CMakeFiles directory. Not ideal.
The use case that I'm interested in is to collect the data to include in something like a pkg-config file. I'm writing a library, and it includes a couple executable utilities that use the library. Building the executables (especially when the library is build statically) requires a non-trivial link line to link to my library and its dependencies. So I'd like to write out the link line necessary for building these executables to a data file included with the package such that other clients can know how to link.
As #Tsyvarev has commented there is no build-in command or property "to programmatically retrieve the complete list of linker flags" in CMake.
But inspired by your hint "so I'd like to write out the link line necessary for building these executables to a data file" I think I found a feasible solution (at least for makefile generators).
And if I understand your request correctly, we are not talking about simple verbose outputs like you get with e.g. CMAKE_VERBOSE_MAKEFILE, which would still need you to copy things manually.
So taking the following into account:
You need to run the generator first to get the real link line
CMake allows you to invent any linker language by name
You can define the link line with CMAKE_>LANG<_LINK_EXECUTABLE using variables and expansion rules
I came up with adding an LinkLine executable using my ECHO "linker" with the single purpose to create a link line file of my choosing:
set(CMAKE_ECHO_STANDARD_LIBRARIES ${CMAKE_CXX_STANDARD_LIBRARIES})
set(CMAKE_ECHO_FLAGS ${CMAKE_CXX_FLAGS})
set(CMAKE_ECHO_LINK_FLAGS ${CMAKE_CXX_LINK_FLAGS})
set(CMAKE_ECHO_IMPLICIT_LINK_DIRECTORIES ${CMAKE_CXX_IMPLICIT_LINK_DIRECTORIES})
set(
CMAKE_ECHO_LINK_EXECUTABLE
"<CMAKE_COMMAND> -E echo \"<FLAGS> <LINK_FLAGS> <LINK_LIBRARIES>\" > <TARGET>"
)
add_executable(LinkLine "")
target_link_libraries(LinkLine MyLibraryTarget)
set_target_properties(
LinkLine
PROPERTIES
LINKER_LANGUAGE ECHO
SUFFIX ".txt"
)
The nice thing about this approach is, that the output of my LinkLine target can be used as any other "officially generated" executable output (e.g. in install() commands or post-build steps with generator expressions):
add_custom_command(
TARGET LinkLine
POST_BUILD
COMMAND ${CMAKE_COMMAND} -E copy $<TARGET_FILE:LinkLine> PackageCfg/$<TARGET_FILE_NAME:LinkLine>
)
References
Recursive list of LINK_LIBRARIES in CMake
add_custom_command is not generating a target
I'd like to link libpng found by pkg-config statically.
pkg-config --libs --static libpng
outputs
-L/usr/local/Cellar/libpng/1.6.15/lib -lpng16 -lz
I have both libpng16.a libpng16.dylib in that directory, and if I use these flags the library gets linked dynamically.
How can I tell either pkg-config or the linker (preferably in some portable-ish way) that I really want it linked statically?
I've tried adding -static before pkg-config's flags, but that makes clang's ld try and fail to link "crt0.o".
The pkg-config --static option relies on proper tagging in the .pc files. If providing the --static option does not return correct information necessary to link against the libpng archive, then you cannot use pkg-config for that purpose.
I suspect libpng (along with a majority of other packages) dropped support for static linking some time after libpng 1.2. They may still provide a library archive, but the libpng pkg-config file is no longer properly tagged to support a static link. You will have to manually tell ld to use the static lib.
Try:
-L/usr/local/Cellar/libpng/1.6.15/lib -l:libpng16.a -lz
Using -l with a : character allows you to specify the filename extension.
The -l: option is documented in the GNU ld 2.24 manual:
-l namespec
--library=namespec
Add the archive or object file specified by namespec to the list of files to link. This option may be used any number of times. If namespec is of the form :filename, ld will search the library path for a file called filename, otherwise it will search the library path for a file called libnamespec.a.
On systems which support shared libraries, ld may also search for files other than libnamespec.a. Specifically, on ELF and SunOS systems, ld will search a directory for a library called libnamespec.so before searching for one called libnamespec.a. (By convention, a .so extension indicates a shared library.) Note that this behavior does not apply to :filename, which always specifies a file called filename.
You could edit the .pc file to make it support static linking, especially if you are in a position to be compiling, patching, and installing software yourself instead of relying on some Linux distribution.
Here is an example of a .pc file that supports both dynamic and static linking. This is taken from /usr/lib/x86_64-linux-gnu/pkgconfig/xcb.pc on my Ubuntu system:
prefix=/usr
exec_prefix=${prefix}
libdir=${prefix}/lib/x86_64-linux-gnu
includedir=${prefix}/include
xcbproto_version=1.11
Name: XCB
Description: X-protocol C Binding
Version: 1.11.1
Requires.private: pthread-stubs xau >= 0.99.2 xdmcp
Libs: -L${libdir} -lxcb
Libs.private:
Cflags: -I${includedir}
If you run pkg-config --libs xcb, it assumes you want the dynamic version and it gives you just -lxcb. The xcb.so dynamically shared object will know how to load all of its own dependencies so you don't have to specify them when linking against it.
If you run pkg-config --libs xcb --static, then the .private fields come into play, and you get -lxcb -lXau -lXdmcp.
I have not encountered many build systems that know to pass the --static argument to pkg-config. So if your .pc file is only intended to support static linking, it's probably best to not use .private fields, and just provide all the dependencies people will need unconditionally. That way people can link against the library successfully even if they don't know it's static or don't know to pass --static to pkg-config.
Just adding to the post by #David Garyson above I would like to add . If a particular
*.pc file is unavailable with the command
pkg-config --libs
then you might need to add a variable to your PATH
Perhaps you should add the directory containing `nice.pc' to the PKG_CONFIG_PATH environment variable
I use this trick in my Makefile.
LIBRARIES := $(shell pkg-config --libs libpng | sed -E 's/-l([a-z0-9]*)/-l:lib\1.a/g')
It grabs output from pkg config and expands it by prefixing each item with : and the lib, and post-fixing it with an .a. The end result is just what you need
-l:libpng.a -l:libz.a
I've been trying to create a CMake-based build-system for a project that is supposed to use SDL2_image library. I do not want to force user to install any libraries to the system to be able to build the project, so I took advantage of the CMake's ability to download and build dependencies (freetype, SDL2 and SDL2_image) from source code as External Projects.
Everything is fine with freetype and SDL2 (which both include CMakeLists.txt files out of the box), but I've ran out of ideas how to make it work for SDL2_image. CMake's external projects support custom configuration and building settings which I used in different variants with no success.
The CMake file itself can be found here, but the problematic part is this:
# SDL_image library
ExternalProject_Add(sdl2_image_project
URL https://www.libsdl.org/projects/SDL_image/release/SDL2_image-2.0.0.tar.gz
DEPENDS sdl2_project
PREFIX ${LIBS_DIR}/SDL2_image
CONFIGURE_COMMAND LDFLAGS=-L${SDL2_BIN} CFLAGS=-I${SDL2_SRC}/include SDL2_CONFIG=${SDL2_BIN}/sdl2-config <SOURCE_DIR>/configure --prefix=<INSTALL_DIR> --enable-shared=no
BUILD_COMMAND make
INSTALL_COMMAND ""
)
An error occurs while building sdl2_image_project. Some trivial research discovered that the error is generated by the undefined references to parts of libdl. Here is a tiny part of the hole error:
libtool: link: gcc -I/home/snikitin/_src/img_glypher/libs/SDL2/src/sdl2_project/include -I/usr/local/include/SDL2 -D_REENTRANT -o showimage showimage.o -Wl,-rpath -Wl,/usr/local/lib -pthread -L/home/snikitin/_src/img_glypher/libs/SDL2/src/sdl2_project-build ./.libs/libSDL2_image.a -L/usr/local/lib -lSDL2 -pthread
/home/snikitin/_src/img_glypher/libs/SDL2/src/sdl2_project-build/libSDL2.a(SDL_dynapi.c.o): In function `get_sdlapi_entry':
/home/snikitin/_src/img_glypher/libs/SDL2/src/sdl2_project/src/dynapi/SDL_dynapi.c:227: undefined reference to `dlopen'
I think the problem takes place due to the fact that linker tries to create a shared version of SDL2_image library while linking it to a static libSDL2.a. The thing is - if this is right - SDL2 building step creates both static and shared versions of itself so one would assume that linker would use libSDL2-2.0.so instead (I do not actually need a shared library - just the static one, but I do not know how to prevent the build system from trying to create it apart from passing --enable-shared=no to SDL2_image configure script, which does not help in this case).
After a lot of googling I've discovered that the possible source of the problem is that sdl2-config (which is called to get some flags for compiler during SDL_image building) may be called with wrong arguments and produces wrong cflags which confuse everything else. But I'm not sure that is the case and also I do not know how to influence sdl2_config call from CMake (configure --help does not seem to unveil any useful options for this situation).
I am running Ubuntu 14.04 x64 if it matters in any way. Would appreciate any advice!
Looks like you need to link some libraries like m and dl. It can be fixed by providing
custom sdl2-config file. Copy sdl2-config from extracted archive and substitute --libs result:
--libs)
echo -L${exec_prefix}/lib -Wl,-rpath,${libdir} -pthread -lSDL2 -lm -ldl
;;
Note that order is important (that's why just modifying LIBS not works for me).
Now this file can be used in your ExternalProject_Add command instead of SDL2_CONFIG=${SDL2_BIN}/sdl2-config:
...
... CFLAGS=-I${SDL2_SRC}/include SDL2_CONFIG=${CMAKE_CURRENT_LIST_DIR}/sdl2-config <SOURCE_DIR>/configure
...
I'm using CMake 2.8 in order to build an application based on MQX OS (using CodeWarrior).
The CMake project basically builds a set of static libraries (let's say LIB1 and LIB2).
I then reference these libraries in the final executable cmake rule:
target_add_executable(X ${some_sources})
target_link_libraries(X LIB1 LIB2)
My problem is that some symbols are defined in more that one library.
Thus, a link command like:
mwldarm <args> -o <output> <objects> /path/to1/libLIB1.a /path/to2/libLIB2.a
would lead to multiple definition of symbols error.
Instead, I would like CMake to generate a link command like:
mwldarm <args> -o <output> <objects> -L/path/to1 -L/path/to2 -lLIB -lLIB2
Question: How to get the following variables from CMAKE?
Libraries directories flags (ex: -L/path/to1 -L/path/to2)
Libraries link flags (ex: -lLIB -lLIB2)
I've read stuff concerning RPATH but it seems to concern shared libraries only. Am I right?
Thanks for advance.
I do appreciate.
It seems that policy CMP0003 may be what you need.
To use it add the following line near the beginning of your CMakeLists.txt:
CMAKE_POLICY( SET CMP0003 OLD )
Another possibility is to directly set the dependencies and search path, however it's not the cleanest way. Assuming you libraries are called liba.a and libb.a, then:
LINK_DIRECTORIES( ${paths_to_search_for} )
TARGET_ADD_EXECUTABLE(X ${some_sources} )
ADD_DEPENDENCIES(X LIB1 LIB2)
TARGET_LINK_LIBRARIES(X a b )
Note that in this case a and b are not cmake targets, therefore a little machinery is needed to correctly set the dependencies.
Part of the design of CMake is that it links with full paths. Why is that a problem?
Toggling the behavior with the policy is not the correct approach.
http://www.cmake.org/gitweb?p=cmake.git;a=commitdiff;h=cd4fa896b
I think CMP0003 is used to switch on/off the function of adding searching path automatically as described in the official document
Libraries linked via full path no longer produce linker search paths.
rather than about replacing the path name with -l.
When linking a library, if the library is a target CMake known, CMake always replaces related -L and -l options with the library's path name. This may not be a problem for linking static libraries. But for a executable to link a shared library, it's may be a problem. Then I found a hacking method, code like below, to solve the problem linking a shread library using -L and `-l' rather than absolute path.
# Find out the link.txt
set(LINK_TXT "${CMAKE_BINARY_DIR}/${ToLinkLib}/CMakeFiles/${ToLinkLIb}.dir/link.txt")
# Add the searching path into link command
add_custom_command(TARGET ${YourTarget} PRE_BUILD
COMMAND sed ARGS -ie "\"s;[[:blank:]]-l; -L${LIBRARY_OUTPUT_PATH} -l;\"" ${LINK_TXT}
DEPENDS ${LINK_TXT}
COMMENT "Hacking CMake: edit __link.txt__ to use -l instead of path to link internal library ...")
# NOTE: Dont't missing the `-l'.
target_link_libraries(${YourTarget} -l${ToLinkLib})
Of course, this is just a hacking so may not be working well with all versions of CMake.
UPDATED: why linking a shared library may be a problem?
When I run a executable cross compiled for android, which linking a shared library built by the same CMake scripts, I've encounter a problem of linking failed. After I used the above hacking method to get a new version, I can run my executable with a command like below
$ LD_LIBRARY_PATH=. ./the_exe opts
I'm building some code using CMake that should be compiled against the ScriptingBridge.
I'm seeing many tens of thousands of log lines such as:
In file included from /Developer/SDKs/MacOSX10.7.sdk/System/Library/Frameworks/Security.framework/Headers/cssmapple.h:30,
from /Developer/SDKs/MacOSX10.7.sdk/System/Library/Frameworks/Security.framework/Headers/Security.h:25,
from /Developer/SDKs/MacOSX10.7.sdk/System/Library/Frameworks/Foundation.framework/Headers/NSURLCredential.h:9,
from /Developer/SDKs/MacOSX10.7.sdk/System/Library/Frameworks/Foundation.framework/Headers/Foundation.h:70,
from /Developer/SDKs/MacOSX10.7.sdk/System/Library/Frameworks/AppKit.framework/Headers/AppKit.h:10,
from /Users/codebeaker/Projects/watchedit-client-code/src/libwhatsplaying/include/apple/itunes.h:5,
from /Users/codebeaker/Projects/watchedit-client-code/src/libwhatsplaying/src/osx/itunes_scripting_bridge.m:1:
/Developer/SDKs/MacOSX10.7.sdk/System/Library/Frameworks/Security.framework/Headers/cssmtype.h:142: warning: ‘CSSM_GUID’ is deprecated
/Developer/SDKs/MacOSX10.7.sdk/System/Library/Frameworks/Security.framework/Headers/cssmtype.h:143: warning: ‘CSSM_VERSION’ is deprecated
/Developer/SDKs/MacOSX10.7.sdk/System/Library/Frameworks/Security.framework/Headers/cssmtype.h:156: warning: ‘CSSM_GUID’ is deprecated
/Developer/SDKs/MacOSX10.7.sdk/System/Library/Frameworks/Security.framework/Headers/cssmtype.h:197: warning: ‘CSSM_DATA’ is deprecated
/Developer/SDKs/MacOSX10.7.sdk/System/Library/Frameworks/Security.framework/Headers/cssmtype.h:217: warning: ‘CSSM_DATA_PTR’ is deprecated
/Developer/SDKs/MacOSX10.7.sdk/System/Library/Frameworks/Security.framework/Headers/cssmtype.h:220: warning: ‘CSSM_DATA’ is deprecated
(Full extensive output here)
The files are being compiled with:
/usr/bin/c++ -I/Users/codebeaker/Projects/watchedit-client-code/src/libwhatsplaying/include -I/Users/codebeaker/Projects/watchedit-client-code/src/libwhatsplaying/../libwatchedit/include -x objective-c -o CMakeFiles/whatsplaying.dir/src/osx/itunes_scripting_bridge.m.o -c /Users/codebeaker/Projects/watchedit-client-code/src/libwhatsplaying/src/osx/itunes_scripting_bridge.m
/usr/bin/gcc -I/Users/codebeaker/Projects/watchedit-client-code/src/libwhatsplaying/include -I/Users/codebeaker/Projects/watchedit-client-code/src/libwhatsplaying/../libwatchedit/include -F/Developer/SDKs/MacOSX10.7.sdk/System/Library/Frameworks -x objective-c -o CMakeFiles/whatsplaying.dir/src/osx/itunes_scripting_bridge.m.o -c /Users/codebeaker/Projects/watchedit-client-code/src/libwhatsplaying/src/osx/itunes_scripting_bridge.m
Having reviewed the man page for (Clang) gcc on my Mac, there's this which sounds interesting:
-Fdir
Add the framework directory dir to the head of the list of directories to be searched for header files. These directories are interleaved with those
specified by -I options and are scanned in a left-to-right order.
A framework directory is a directory with frameworks in it. A framework is a directory with a "Headers" and/or "PrivateHeaders" directory contained
directly in it that ends in ".framework". The name of a framework is the name of this directory excluding the ".framework". Headers associated with
the framework are found in one of those two directories, with "Headers" being searched first. A subframework is a framework directory that is in a
framework's "Frameworks" directory. Includes of subframework headers can only appear in a header of a framework that contains the subframework, or in
a sibling subframework header. Two subframeworks are siblings if they occur in the same framework. A subframework should not have the same name as a
framework, a warning will be issued if this is violated. Currently a subframework cannot have subframeworks, in the future, the mechanism may be
extended to support this. The standard frameworks can be found in "/System/Library/Frameworks" and "/Library/Frameworks". An example include looks
like "#include ", where Framework denotes the name of the framework and header.h is found in the "PrivateHeaders" or "Headers"
directory.
-iframeworkdir
Like -F except the directory is a treated as a system directory. The main effect is to not warn about constructs contained within header files found
via dir.
Maybe I ought to be looking for -iframework. When building with -iframework on the terminal, manually this completes without any deprecation warnings.
However CMake doesn't support an option to use -framework. From their find_library() documentation:
CMake will use a -framework A, and a -F to link the framework to the target.
I'm looking for any way to have a quiet build. I also have (4x) smaller warnings from OpenSSL'x EVA interface, those I can handle... thanks in advance.
The answer was to use -iframework, probably as this is intended to ignore system level deprecation warnings when you can't resolve them.
Instead I was able to use -Wno-deprecated-declarations, a flag to GCC which is documented and available everywhere. It's reliable, and I include it in my CMake declaration as such:
IF(${CMAKE_SYSTEM_NAME} MATCHES "Darwin")
find_and_add_framework(Foundation watchedit)
find_and_add_framework(Cocoa watchedit)
find_and_add_framework(AppKit watchedit)
find_and_add_framework(ScriptingBridge watchedit)
set_source_files_properties(${sources} PROPERTIES COMPILE_FLAGS
"-xobjective-c -Wno-deprecated-declarations")
set_source_files_properties(${sources} PROPERTIES LANGUAGE C)
ENDIF(${CMAKE_SYSTEM_NAME} MATCHES "Darwin")
For anyone who would benefit, here's the implementation of find_and_add_framework. I'm not sure where I cribbed it from, but it's not my own work:
macro(FIND_AND_ADD_FRAMEWORK fwname appname)
find_library(FRAMEWORK_${fwname}
NAMES ${fwname}
PATHS ${CMAKE_OSX_SYSROOT}/System/Library
PATH_SUFFIXES Frameworks
NO_DEFAULT_PATH)
if( ${FRAMEWORK_${fwname}} STREQUAL FRAMEWORK_${fwname}-NOTFOUND)
MESSAGE(ERROR ": Framework ${fwname} not found")
else()
TARGET_LINK_LIBRARIES(${appname} ${FRAMEWORK_${fwname}})
# MESSAGE(STATUS "Framework ${fwname} found at ${FRAMEWORK_${fwname}}")
endif()
endmacro(FIND_AND_ADD_FRAMEWORK)