I have configure.ac which is designed for building a shared library (both linux and macos). Now I'd like to add special demo app which uses this library and shows its features. However this demo app is only for MacOS and has .mm file in it (main.mm). I'm trying to define a target for this demo app in this way:
if OS_DARWIN
EXTRA_PROGRAMS = app-demo
app_demo_CC = OBJC
app_demo_CXX = OBJC
app_demo_SOURCES = demoapp/config.cc demoapp/config.h \
demoapp/main.mm demoapp/AppDelegate.m \
demoapp/renderer-stub.cc demoapp/renderer-stub.h \
demoapp/view.cc demoapp/view.h
app_demo_CPPFLAGS = ... # include directories here
app_demo_LDFLAGS = ... # libraries and library search paths
endif
That's my top-level Makefile.am and as you can see, demoapp folder has all the sources for the demo app and two Objective-C files: main.mm and AppDelegate.m.
However, when I try to run make app-demo, I'm getting this:
Undefined symbols for architecture x86_64:
"_main", referenced from:
implicit entry/start for main executable
Which means (and I confirm it from the make logs) that main.mm hasn't been compiled, neither linked.
Does anyone knows workarounds for this?
I don't think this is enough information to debug the problem.
I think automake supports ObjC++. Do you get errors when invoking automake? Does your configure.ac invoke AC_PROG_OBJCXX? If you try compiling the files by hand, does it work?
Resolved by defining separate target in Makefile.am like this:
.mm.o :
$(OBJCXX) -x objective-c++ -c #DEFS# $(CPPFLAGS) $(app_demo_CPPFLAGS) $< -o $#
Related
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.
I'm playing around with bare-metal x86 and I've hit a snag porting my build from straight-up makefiles to cmake.
In my makefile my objects are defined like this:
LINK_LIST=\
$(LDFLAGS) \
$(ARCHDIR)/crti.o \
$(ARCHDIR)/crtbegin.o \
$(KERNEL_OBJS) \
$(LIBS) \
$(ARCHDIR)/crtend.o \
$(ARCHDIR)/crtn.o \
crtbegin.o and crtend.o are 'generated', that is, provided by my cross-compiler (-print-file-name flag). $(LIBS) are -l flags, like -lgcc, etc. Since this is passed directly to the linker the order is as specified.
My cmake target is defines as follows:
ADD_EXECUTABLE(loader
"${INIT_SRC}"
"${INIT_OBJ}"
"${PLATFORM_SRCS}"
"${ISA_SRCS}"
"${GENERIC_SRCS}"
"${FINI_OBJ}"
"${FINI_SRC}")
INIT_OBJ and FINI_OBJ have EXTERNAL_OBJECT and GENERATED set to true in source file properties. Looking at the command line when running the generated makefile I see that all source files are in the order specified, but init and fini objects are last in the list.
Here is the resulting command line (edited for brevity):
i686-elf-gcc -nostdlib -ffreestanding -nostdinc -T linker.ld -lgcc crti.s.obj boot.s.obj loader.c.obj crtn.s.obj crtbegin.o crtend.o -o loader
The -lgcc flag is explicit in my LINK_FLAGS, which is also something I would like to change.
So I have a few questions regarding this:
Why isn't cmake using the order for the two external object files, but IS using it for the compiled ones?
How can I tell cmake to treat these objects the same as the ones coming from my sources?
How could I get a complete clone of the setup I have in my Makefile (with the library flags between my object files)
I did also check out CMAKE_C_LINK_EXECUTABLE as well, but it doesn't seem to have enough granularity/control over the linker params to achieve this.
I'm using cmake 3.10.2 on ubuntu.
And another (off-topic) question about cmake:
It doesn't treat .S as a standard assembly file extension. I tried adding it with LIST(APPEND CMAKE_ASM-ATT_SOURCE_FILE_EXTENSIONS S), and it does add it just fine, however the files still aren't getting compiled unless I change it to .s. Has anyone else had this issue?
Thanks!
Objects crtbegin.o and crtend.o, which has specific requirement about position in the link command, may be treated as a part of toolchain. If you decide that, then you can set the variable CMAKE_C_LINK_EXECUTABLE to reflect this specific:
SET(ARCHDIR "<...>")
# Object 'crtbegin.o' will be linked before all other objects and libraries.
# Object 'crtend.o' will be linked after all other objects and libraries.
SET(CMAKE_C_LINK_EXECUTABLE "<CMAKE_C_COMPILER> <FLAGS> <CMAKE_C_LINK_FLAGS>
<LINK_FLAGS>
${ARCHDIR}/crtbegin.o
<OBJECTS> -o <TARGET> <LINK_LIBRARIES>
${ARCHDIR}/crtend.o")
This setting should be done in the toolchain file, which is passed to cmake with option -DCMAKE_TOOLCHAIN=<path/to/toolchain/file>.
With such toolchain, in the CMakeLists.txt you may simply write
ADD_EXECUTABLE(loader ${PLATFORM_SRCS} ${ISA_SRCS} ${GENERIC_SRCS})
Using CMAKE_C_LINK_EXECUTABLE variable you may also position options such as
-nostdlib -ffreestanding -nostdinc -T linker.ld -lgcc
which are very toolchain-related too.
See also this mailing: https://cmake.org/pipermail/cmake/2010-June/037641.html.
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
What options set, to statically linked the library curl ?
Library should be integrated to executable file.
tried different: added options g++ -DCURL_STATICLIB -lcurl ... added #define CURL_STATICLIB to the code ..., in the IDE NetBeans added libcurl.a, libcurldll.a ... etc.,
Compile is successful and all works great. But still require external libcurl.dll! (Size of executable file also increases!)
What's wrong ? might have something add to the IDE (also used NetBeans, Eclipse)
Please show a correct example as you would make
Executable file should be without calling an external dll library
it my first question :)
Fix.
Example compile for library curl with OpenSSL + zlib + libidn + libssh2 + librtmp:
g++ -static main.cpp -lcurl -lidn -lwldap32 -lssh2 -lz -lrtmp -lssl -lssl32 -lcrypto -lgdi32 -lws2_32 -lwinmm -o test.exe
note: here shouldn't be specified -lcurldll. This will lead to that: compile is successful, but still require external libcurl.dll
you need to specify -static in the linker options