Re: [CMake] Weird linking error while cross compiling
On 10/28/2011 06:20 PM, Jose wrote:
I give up. [...]
Never say die. ;)
[...] I solved the problem with the solution Michael gave me. Actually
this linking flag : -Bstatic
was the causant of the troubles.
Out of curiosity: We've seen the failing link line; how does the
successful one look alike? Do you still use the -Bstatic flag?
Nevertheless now I get undefined references to functions defined in the
library portablexdr .
I have been trying to fix it for two days without success. The library is
being linked and I have checked the content of the library with
mingw32-nm and it has all the functions defined.
I have to say that I modified and rebuilt the library to include some
functions that were not present ( portableXDR does not follow the Sun XDR
standard). So I guess this is what it is
causing me the troubles but It should not since I rebuilt it without
problems and when I check the content of the library with nm the functions
are there.
Any help??
Could you provide some more information, i.e. excerpts from the make
VERBOSE=1 output and the concerned CMakeLists.txt files, especially
the latters' TARGET_LINK_LIBRARIES() commands? Ideally, you should
post a small self-contained example which demonstrates the issue.
Regards,
Michael
2011/10/26 Michael Hertling mhertl...@online.de
On 10/26/2011 10:28 AM, Andreas Pakulat wrote:
On 26.10.11 03:54:02, Jose wrote:
Sorry for not being very specific.
This is the command that Cmake is running while linking :
/usr/bin/i686-pc-mingw32-g++ -O3 -O3-Wl,-Bstatic -static-libgcc
-Wl,--whole-archive CMakeFiles/sqt2pin.dir/objects.a
-Wl,--no-whole-archive
-o sqt2pin.exe -Wl,--out-implib,libsqt2pin.dll.a
-Wl,--major-image-version,0,--minor-image-version,0
-L/home/fedora/percolator/percolator/src/converters/../../src
libconverters.a libperclibrary_part.a MSToolkit/libMSToolkit.a
MSToolkit/RAMP/libRAMP.a -lxerces-c -lportablexdr
/home/fedora/percolator/percolator/src/converters/libs/dll/libtokyocabinet.a
-lz -lsqlite3 -Wl,-Bstatic -lkernel32 -luser32 -lgdi32 -lwinspool
-lshell32
-lole32 -loleaut32 -luuid -lcomdlg32 -ladvapi32
/usr/lib/gcc/i686-pc-mingw32/4.5.3/../../../../i686-pc-mingw32/bin/ld:
cannot find -lxerces-c
/usr/lib/gcc/i686-pc-mingw32/4.5.3/../../../../i686-pc-mingw32/bin/ld:
cannot find -lportablexdr
/usr/lib/gcc/i686-pc-mingw32/4.5.3/../../../../i686-pc-mingw32/bin/ld:
cannot find -lz
/usr/lib/gcc/i686-pc-mingw32/4.5.3/../../../../i686-pc-mingw32/bin/ld:
cannot find -lsqlite3
That is weird cos I load all the libraries in the same way and they
all
the variables content the right paths to the libraries : (for example)
Xercesc : /usr/i686-pc-mingw32/sys-root/mingw/lib/libxerces-c.dll.a ,
XDR :
/usr/i686-pc-mingw32/sys-root/mingw/lib/libportablexdr.dll.a
This is how I link :
#COMPILING SQT2PIN
include_directories(. MSToolkit/RAMP MSToolkit )
add_executable(sqt2pin Sqt2Pin.cpp )
IF(STATIC AND MINGW)
set_property(TARGET sqt2pin PROPERTY LINK_SEARCH_END_STATIC ON)
set_target_properties(sqt2pin PROPERTIES LINK_FLAGS -Wl,-Bstatic
-static-libgcc)
ENDIF()
message(STATUS Xercesc : ${XERCESC_LIBRARIES} , XDR :
${PORTABLEXDR_LIBRARIES})
target_link_libraries(sqt2pin converters perclibrary_part MSToolkit
RAMP
${XERCESC_LIBRARIES} ${PORTABLEXDR_LIBRARIES} ${TOKYOCABINET_LIBRARIES}
)
I might be missing something very stupid because I use the same
prodecure
to search for the librarysthe FindXXX.cmake macros that are tested
and
working with other programs.
Could it be the include_directories(library include dir) which is
messing
this up? it looks like the linker disregard the path of the library that
Im
pasinng and looks for -lxerces-c instead. Is that xerces-c defined
somehow
before?
This happens if the library is considered to be in a 'system path' since
in that case specifying the path is not necessary for the linker to find
it. However in your specific case it seems like cmake does this even for
static libraries, which is of course wrong. I'd suggest to file a
bugreport for this with a small self-contained example.
Andreas
The -l switch of ld is not related to the library's type, i.e.
shared or static; see ld's manpage and the following example:
CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(STATIC C)
SET(CMAKE_VERBOSE_MAKEFILE ON)
FILE(WRITE ${CMAKE_BINARY_DIR}/f.c int f(void){return 0;}\n)
EXECUTE_PROCESS(COMMAND ${CMAKE_C_COMPILER} -c f.c)
EXECUTE_PROCESS(COMMAND ${CMAKE_AR} cr libf.a f.o)
FILE(WRITE ${CMAKE_BINARY_DIR}/main.c int main(void){return f();}\n)
ADD_EXECUTABLE(main main.c)
TARGET_LINK_LIBRARIES(main -L${CMAKE_BINARY_DIR} f /usr/lib/libz.a)
The executable main is linked against the static libf.a via the -l
switch. Usually, in particular on ELF systems, ld just prefers shared
libraries with -l unless it is told to not do so, e.g. using -Bstatic.
However, MinGW's ld behaves differently in this regard; IIRC, it even
Re: [CMake] Weird linking error while cross compiling
I give up. I solved the problem with the solution Michael gave me. Actually
this linking flag : -Bstatic
was the causant of the troubles.
Nevertheless now I get undefined references to functions defined in the
library portablexdr .
I have been trying to fix it for two days without success. The library is
being linked and I have checked the content of the library with
mingw32-nm and it has all the functions defined.
I have to say that I modified and rebuilt the library to include some
functions that were not present ( portableXDR does not follow the Sun XDR
standard). So I guess this is what it is
causing me the troubles but It should not since I rebuilt it without
problems and when I check the content of the library with nm the functions
are there.
Any help??
Thank you
Jose
2011/10/26 Michael Hertling mhertl...@online.de
On 10/26/2011 10:28 AM, Andreas Pakulat wrote:
On 26.10.11 03:54:02, Jose wrote:
Sorry for not being very specific.
This is the command that Cmake is running while linking :
/usr/bin/i686-pc-mingw32-g++ -O3 -O3-Wl,-Bstatic -static-libgcc
-Wl,--whole-archive CMakeFiles/sqt2pin.dir/objects.a
-Wl,--no-whole-archive
-o sqt2pin.exe -Wl,--out-implib,libsqt2pin.dll.a
-Wl,--major-image-version,0,--minor-image-version,0
-L/home/fedora/percolator/percolator/src/converters/../../src
libconverters.a libperclibrary_part.a MSToolkit/libMSToolkit.a
MSToolkit/RAMP/libRAMP.a -lxerces-c -lportablexdr
/home/fedora/percolator/percolator/src/converters/libs/dll/libtokyocabinet.a
-lz -lsqlite3 -Wl,-Bstatic -lkernel32 -luser32 -lgdi32 -lwinspool
-lshell32
-lole32 -loleaut32 -luuid -lcomdlg32 -ladvapi32
/usr/lib/gcc/i686-pc-mingw32/4.5.3/../../../../i686-pc-mingw32/bin/ld:
cannot find -lxerces-c
/usr/lib/gcc/i686-pc-mingw32/4.5.3/../../../../i686-pc-mingw32/bin/ld:
cannot find -lportablexdr
/usr/lib/gcc/i686-pc-mingw32/4.5.3/../../../../i686-pc-mingw32/bin/ld:
cannot find -lz
/usr/lib/gcc/i686-pc-mingw32/4.5.3/../../../../i686-pc-mingw32/bin/ld:
cannot find -lsqlite3
That is weird cos I load all the libraries in the same way and they
all
the variables content the right paths to the libraries : (for example)
Xercesc : /usr/i686-pc-mingw32/sys-root/mingw/lib/libxerces-c.dll.a ,
XDR :
/usr/i686-pc-mingw32/sys-root/mingw/lib/libportablexdr.dll.a
This is how I link :
#COMPILING SQT2PIN
include_directories(. MSToolkit/RAMP MSToolkit )
add_executable(sqt2pin Sqt2Pin.cpp )
IF(STATIC AND MINGW)
set_property(TARGET sqt2pin PROPERTY LINK_SEARCH_END_STATIC ON)
set_target_properties(sqt2pin PROPERTIES LINK_FLAGS -Wl,-Bstatic
-static-libgcc)
ENDIF()
message(STATUS Xercesc : ${XERCESC_LIBRARIES} , XDR :
${PORTABLEXDR_LIBRARIES})
target_link_libraries(sqt2pin converters perclibrary_part MSToolkit
RAMP
${XERCESC_LIBRARIES} ${PORTABLEXDR_LIBRARIES} ${TOKYOCABINET_LIBRARIES}
)
I might be missing something very stupid because I use the same
prodecure
to search for the librarysthe FindXXX.cmake macros that are tested
and
working with other programs.
Could it be the include_directories(library include dir) which is
messing
this up? it looks like the linker disregard the path of the library that
Im
pasinng and looks for -lxerces-c instead. Is that xerces-c defined
somehow
before?
This happens if the library is considered to be in a 'system path' since
in that case specifying the path is not necessary for the linker to find
it. However in your specific case it seems like cmake does this even for
static libraries, which is of course wrong. I'd suggest to file a
bugreport for this with a small self-contained example.
Andreas
The -l switch of ld is not related to the library's type, i.e.
shared or static; see ld's manpage and the following example:
CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(STATIC C)
SET(CMAKE_VERBOSE_MAKEFILE ON)
FILE(WRITE ${CMAKE_BINARY_DIR}/f.c int f(void){return 0;}\n)
EXECUTE_PROCESS(COMMAND ${CMAKE_C_COMPILER} -c f.c)
EXECUTE_PROCESS(COMMAND ${CMAKE_AR} cr libf.a f.o)
FILE(WRITE ${CMAKE_BINARY_DIR}/main.c int main(void){return f();}\n)
ADD_EXECUTABLE(main main.c)
TARGET_LINK_LIBRARIES(main -L${CMAKE_BINARY_DIR} f /usr/lib/libz.a)
The executable main is linked against the static libf.a via the -l
switch. Usually, in particular on ELF systems, ld just prefers shared
libraries with -l unless it is told to not do so, e.g. using -Bstatic.
However, MinGW's ld behaves differently in this regard; IIRC, it even
prefers static and import libraries to shared ones with the -l switch.
BTW, /usr/lib/libz.a is converted into -Wl,-Bstatic -lz -Wl,-Bdynamic
due to /usr/lib being a system directory, i.e. CMake performs this -l
conversion of full paths in system directories for static libraries,
too; why should it be called wrong?
Jose, could you find out which directories CMake considers as system
directories and if these are actually
Re: [CMake] Weird linking error while cross compiling
Sorry for not being very specific.
This is the command that Cmake is running while linking :
/usr/bin/i686-pc-mingw32-g++ -O3 -O3-Wl,-Bstatic -static-libgcc
-Wl,--whole-archive CMakeFiles/sqt2pin.dir/objects.a -Wl,--no-whole-archive
-o sqt2pin.exe -Wl,--out-implib,libsqt2pin.dll.a
-Wl,--major-image-version,0,--minor-image-version,0
-L/home/fedora/percolator/percolator/src/converters/../../src
libconverters.a libperclibrary_part.a MSToolkit/libMSToolkit.a
MSToolkit/RAMP/libRAMP.a -lxerces-c -lportablexdr
/home/fedora/percolator/percolator/src/converters/libs/dll/libtokyocabinet.a
-lz -lsqlite3 -Wl,-Bstatic -lkernel32 -luser32 -lgdi32 -lwinspool -lshell32
-lole32 -loleaut32 -luuid -lcomdlg32 -ladvapi32
/usr/lib/gcc/i686-pc-mingw32/4.5.3/../../../../i686-pc-mingw32/bin/ld:
cannot find -lxerces-c
/usr/lib/gcc/i686-pc-mingw32/4.5.3/../../../../i686-pc-mingw32/bin/ld:
cannot find -lportablexdr
/usr/lib/gcc/i686-pc-mingw32/4.5.3/../../../../i686-pc-mingw32/bin/ld:
cannot find -lz
/usr/lib/gcc/i686-pc-mingw32/4.5.3/../../../../i686-pc-mingw32/bin/ld:
cannot find -lsqlite3
That is weird cos I load all the libraries in the same way and they all
the variables content the right paths to the libraries : (for example)
Xercesc : /usr/i686-pc-mingw32/sys-root/mingw/lib/libxerces-c.dll.a , XDR :
/usr/i686-pc-mingw32/sys-root/mingw/lib/libportablexdr.dll.a
This is how I link :
#COMPILING SQT2PIN
include_directories(. MSToolkit/RAMP MSToolkit )
add_executable(sqt2pin Sqt2Pin.cpp )
IF(STATIC AND MINGW)
set_property(TARGET sqt2pin PROPERTY LINK_SEARCH_END_STATIC ON)
set_target_properties(sqt2pin PROPERTIES LINK_FLAGS -Wl,-Bstatic
-static-libgcc)
ENDIF()
message(STATUS Xercesc : ${XERCESC_LIBRARIES} , XDR :
${PORTABLEXDR_LIBRARIES})
target_link_libraries(sqt2pin converters perclibrary_part MSToolkit RAMP
${XERCESC_LIBRARIES} ${PORTABLEXDR_LIBRARIES} ${TOKYOCABINET_LIBRARIES} )
I might be missing something very stupid because I use the same prodecure
to search for the librarysthe FindXXX.cmake macros that are tested and
working with other programs.
Could it be the include_directories(library include dir) which is messing
this up? it looks like the linker disregard the path of the library that Im
pasinng and looks for -lxerces-c instead. Is that xerces-c defined somehow
before?
Thank you so much
Jose
2011/10/25 Andreas Pakulat ap...@gmx.de
On 25.10.11 13:15:37, Jose wrote:
Hi all,
I'm cross compiling an app under Fedora. I get this linking errors while
building with cmake :
/usr/lib/gcc/i686-pc-mingw32/4.5.3/../../../../i686-pc-mingw32/bin/ld:
cannot find -lxerces-c
/usr/lib/gcc/i686-pc-mingw32/4.5.3/../../../../i686-pc-mingw32/bin/ld:
cannot find -lportablexdr
/usr/lib/gcc/i686-pc-mingw32/4.5.3/../../../../i686-pc-mingw32/bin/ld:
cannot find -lz
/usr/lib/gcc/i686-pc-mingw32/4.5.3/../../../../i686-pc-mingw32/bin/ld:
cannot find -lsqlite3
The thing is that the libraries have been found,included and linked with
target_link_libraries. I'm adding all the necessary flags to link
statically
and the libraries are the ones included in the mingw package. It shoud
work
because a different part of the application that uses almost the same
libraries is cross compiling perfectly. The cmake files are actually
pretty
much the same so I don't really know what I'm doing wrong. Cmake might be
missing the libraries or the path of the libraries
Hmm, -lfoo means the linker will search for a shared library. Linking
static libraries is done by specifying the absolute path to the library
file. How exactly are you calling target_link_libraries and assuming
that you're passing above libraries via cmake-variables whats the
content of those variables?
Andreas
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Weird linking error while cross compiling
On 26.10.11 03:54:02, Jose wrote:
Sorry for not being very specific.
This is the command that Cmake is running while linking :
/usr/bin/i686-pc-mingw32-g++ -O3 -O3-Wl,-Bstatic -static-libgcc
-Wl,--whole-archive CMakeFiles/sqt2pin.dir/objects.a -Wl,--no-whole-archive
-o sqt2pin.exe -Wl,--out-implib,libsqt2pin.dll.a
-Wl,--major-image-version,0,--minor-image-version,0
-L/home/fedora/percolator/percolator/src/converters/../../src
libconverters.a libperclibrary_part.a MSToolkit/libMSToolkit.a
MSToolkit/RAMP/libRAMP.a -lxerces-c -lportablexdr
/home/fedora/percolator/percolator/src/converters/libs/dll/libtokyocabinet.a
-lz -lsqlite3 -Wl,-Bstatic -lkernel32 -luser32 -lgdi32 -lwinspool -lshell32
-lole32 -loleaut32 -luuid -lcomdlg32 -ladvapi32
/usr/lib/gcc/i686-pc-mingw32/4.5.3/../../../../i686-pc-mingw32/bin/ld:
cannot find -lxerces-c
/usr/lib/gcc/i686-pc-mingw32/4.5.3/../../../../i686-pc-mingw32/bin/ld:
cannot find -lportablexdr
/usr/lib/gcc/i686-pc-mingw32/4.5.3/../../../../i686-pc-mingw32/bin/ld:
cannot find -lz
/usr/lib/gcc/i686-pc-mingw32/4.5.3/../../../../i686-pc-mingw32/bin/ld:
cannot find -lsqlite3
That is weird cos I load all the libraries in the same way and they all
the variables content the right paths to the libraries : (for example)
Xercesc : /usr/i686-pc-mingw32/sys-root/mingw/lib/libxerces-c.dll.a , XDR :
/usr/i686-pc-mingw32/sys-root/mingw/lib/libportablexdr.dll.a
This is how I link :
#COMPILING SQT2PIN
include_directories(. MSToolkit/RAMP MSToolkit )
add_executable(sqt2pin Sqt2Pin.cpp )
IF(STATIC AND MINGW)
set_property(TARGET sqt2pin PROPERTY LINK_SEARCH_END_STATIC ON)
set_target_properties(sqt2pin PROPERTIES LINK_FLAGS -Wl,-Bstatic
-static-libgcc)
ENDIF()
message(STATUS Xercesc : ${XERCESC_LIBRARIES} , XDR :
${PORTABLEXDR_LIBRARIES})
target_link_libraries(sqt2pin converters perclibrary_part MSToolkit RAMP
${XERCESC_LIBRARIES} ${PORTABLEXDR_LIBRARIES} ${TOKYOCABINET_LIBRARIES} )
I might be missing something very stupid because I use the same prodecure
to search for the librarysthe FindXXX.cmake macros that are tested and
working with other programs.
Could it be the include_directories(library include dir) which is messing
this up? it looks like the linker disregard the path of the library that Im
pasinng and looks for -lxerces-c instead. Is that xerces-c defined somehow
before?
This happens if the library is considered to be in a 'system path' since
in that case specifying the path is not necessary for the linker to find
it. However in your specific case it seems like cmake does this even for
static libraries, which is of course wrong. I'd suggest to file a
bugreport for this with a small self-contained example.
Andreas
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Weird linking error while cross compiling
On 10/26/2011 10:28 AM, Andreas Pakulat wrote:
On 26.10.11 03:54:02, Jose wrote:
Sorry for not being very specific.
This is the command that Cmake is running while linking :
/usr/bin/i686-pc-mingw32-g++ -O3 -O3-Wl,-Bstatic -static-libgcc
-Wl,--whole-archive CMakeFiles/sqt2pin.dir/objects.a -Wl,--no-whole-archive
-o sqt2pin.exe -Wl,--out-implib,libsqt2pin.dll.a
-Wl,--major-image-version,0,--minor-image-version,0
-L/home/fedora/percolator/percolator/src/converters/../../src
libconverters.a libperclibrary_part.a MSToolkit/libMSToolkit.a
MSToolkit/RAMP/libRAMP.a -lxerces-c -lportablexdr
/home/fedora/percolator/percolator/src/converters/libs/dll/libtokyocabinet.a
-lz -lsqlite3 -Wl,-Bstatic -lkernel32 -luser32 -lgdi32 -lwinspool -lshell32
-lole32 -loleaut32 -luuid -lcomdlg32 -ladvapi32
/usr/lib/gcc/i686-pc-mingw32/4.5.3/../../../../i686-pc-mingw32/bin/ld:
cannot find -lxerces-c
/usr/lib/gcc/i686-pc-mingw32/4.5.3/../../../../i686-pc-mingw32/bin/ld:
cannot find -lportablexdr
/usr/lib/gcc/i686-pc-mingw32/4.5.3/../../../../i686-pc-mingw32/bin/ld:
cannot find -lz
/usr/lib/gcc/i686-pc-mingw32/4.5.3/../../../../i686-pc-mingw32/bin/ld:
cannot find -lsqlite3
That is weird cos I load all the libraries in the same way and they all
the variables content the right paths to the libraries : (for example)
Xercesc : /usr/i686-pc-mingw32/sys-root/mingw/lib/libxerces-c.dll.a , XDR :
/usr/i686-pc-mingw32/sys-root/mingw/lib/libportablexdr.dll.a
This is how I link :
#COMPILING SQT2PIN
include_directories(. MSToolkit/RAMP MSToolkit )
add_executable(sqt2pin Sqt2Pin.cpp )
IF(STATIC AND MINGW)
set_property(TARGET sqt2pin PROPERTY LINK_SEARCH_END_STATIC ON)
set_target_properties(sqt2pin PROPERTIES LINK_FLAGS -Wl,-Bstatic
-static-libgcc)
ENDIF()
message(STATUS Xercesc : ${XERCESC_LIBRARIES} , XDR :
${PORTABLEXDR_LIBRARIES})
target_link_libraries(sqt2pin converters perclibrary_part MSToolkit RAMP
${XERCESC_LIBRARIES} ${PORTABLEXDR_LIBRARIES} ${TOKYOCABINET_LIBRARIES} )
I might be missing something very stupid because I use the same prodecure
to search for the librarysthe FindXXX.cmake macros that are tested and
working with other programs.
Could it be the include_directories(library include dir) which is messing
this up? it looks like the linker disregard the path of the library that Im
pasinng and looks for -lxerces-c instead. Is that xerces-c defined somehow
before?
This happens if the library is considered to be in a 'system path' since
in that case specifying the path is not necessary for the linker to find
it. However in your specific case it seems like cmake does this even for
static libraries, which is of course wrong. I'd suggest to file a
bugreport for this with a small self-contained example.
Andreas
The -l switch of ld is not related to the library's type, i.e.
shared or static; see ld's manpage and the following example:
CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(STATIC C)
SET(CMAKE_VERBOSE_MAKEFILE ON)
FILE(WRITE ${CMAKE_BINARY_DIR}/f.c int f(void){return 0;}\n)
EXECUTE_PROCESS(COMMAND ${CMAKE_C_COMPILER} -c f.c)
EXECUTE_PROCESS(COMMAND ${CMAKE_AR} cr libf.a f.o)
FILE(WRITE ${CMAKE_BINARY_DIR}/main.c int main(void){return f();}\n)
ADD_EXECUTABLE(main main.c)
TARGET_LINK_LIBRARIES(main -L${CMAKE_BINARY_DIR} f /usr/lib/libz.a)
The executable main is linked against the static libf.a via the -l
switch. Usually, in particular on ELF systems, ld just prefers shared
libraries with -l unless it is told to not do so, e.g. using -Bstatic.
However, MinGW's ld behaves differently in this regard; IIRC, it even
prefers static and import libraries to shared ones with the -l switch.
BTW, /usr/lib/libz.a is converted into -Wl,-Bstatic -lz -Wl,-Bdynamic
due to /usr/lib being a system directory, i.e. CMake performs this -l
conversion of full paths in system directories for static libraries,
too; why should it be called wrong?
Jose, could you find out which directories CMake considers as system
directories and if these are actually searched implicitly by ld? If
CMake takes /usr/i686-pc-mingw32/sys-root/mingw/lib as system dir,
thus libxerces-c.dll.a -- -lxerces-c, but ld does not search it
without a proper -L switch, the issue would be quite clear. As
a quick workaround, you might use imported targets for the
concerned libraries to avoid the -l conversion, i.e.:
ADD_LIBRARY(xerces-c STATIC IMPORTED)
SET_TARGET_PROPERTIES(xerces-c PROPERTIES IMPORTED_LOCATION
/usr/i686-pc-mingw32/sys-root/mingw/lib/libxerces-c.dll.a)
TARGET_LINK_LIBRARIES(... xerces-c ...)
'hope that helps.
Regards,
Michael
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Weird linking error while cross compiling
On Tue, Oct 25, 2011 at 10:15 AM, Jose jc.fernandez.nava...@gmail.com wrote: /usr/lib/gcc/i686-pc-mingw32/4.5.3/../../../../i686-pc-mingw32/bin/ld: cannot find -lsqlite3 The way I usually track down things like this is to find the broken commandline (e.g. make VERBOSE=1), put it in a shell script with any needed cd, and verify that it reproduces the problem. You can then do things like add options to gcc to get it to show what it's doing, or use strace -f -o slog on the script to see where it's looking for the library in question. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Weird linking error while cross compiling
On 25.10.11 13:15:37, Jose wrote: Hi all, I'm cross compiling an app under Fedora. I get this linking errors while building with cmake : /usr/lib/gcc/i686-pc-mingw32/4.5.3/../../../../i686-pc-mingw32/bin/ld: cannot find -lxerces-c /usr/lib/gcc/i686-pc-mingw32/4.5.3/../../../../i686-pc-mingw32/bin/ld: cannot find -lportablexdr /usr/lib/gcc/i686-pc-mingw32/4.5.3/../../../../i686-pc-mingw32/bin/ld: cannot find -lz /usr/lib/gcc/i686-pc-mingw32/4.5.3/../../../../i686-pc-mingw32/bin/ld: cannot find -lsqlite3 The thing is that the libraries have been found,included and linked with target_link_libraries. I'm adding all the necessary flags to link statically and the libraries are the ones included in the mingw package. It shoud work because a different part of the application that uses almost the same libraries is cross compiling perfectly. The cmake files are actually pretty much the same so I don't really know what I'm doing wrong. Cmake might be missing the libraries or the path of the libraries Hmm, -lfoo means the linker will search for a shared library. Linking static libraries is done by specifying the absolute path to the library file. How exactly are you calling target_link_libraries and assuming that you're passing above libraries via cmake-variables whats the content of those variables? Andreas -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
