I give up. I solved the problem with the solution Michael gave me. Actually this linking flag : -Bstatic<br>was the causant of the troubles.<br><br>Nevertheless now I get undefined references to functions defined in the library &quot;portablexdr&quot; .<br>
<br>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 <br>mingw32-nm and it has all the functions defined.<br><br>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<br>
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.<br><br>Any help??<br><br>Thank you<br><br>Jose<br><br><div class="gmail_quote">
2011/10/26 Michael Hertling <span dir="ltr">&lt;<a href="mailto:mhertling@online.de">mhertling@online.de</a>&gt;</span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div><div></div><div class="h5">On 10/26/2011 10:28 AM, Andreas Pakulat wrote:<br>
&gt; On 26.10.11 03:54:02, Jose wrote:<br>
&gt;&gt; Sorry for not being very specific.<br>
&gt;&gt;<br>
&gt;&gt; This is the command that Cmake is running while linking :<br>
&gt;&gt;<br>
&gt;&gt; /usr/bin/i686-pc-mingw32-g++  -O3 -O3    -Wl,-Bstatic -static-libgcc<br>
&gt;&gt; -Wl,--whole-archive CMakeFiles/sqt2pin.dir/objects.a -Wl,--no-whole-archive<br>
&gt;&gt; -o sqt2pin.exe -Wl,--out-implib,libsqt2pin.dll.a<br>
&gt;&gt; -Wl,--major-image-version,0,--minor-image-version,0<br>
&gt;&gt; -L/home/fedora/percolator/percolator/src/converters/../../src<br>
&gt;&gt; libconverters.a libperclibrary_part.a MSToolkit/libMSToolkit.a<br>
&gt;&gt; MSToolkit/RAMP/libRAMP.a -lxerces-c -lportablexdr<br>
&gt;&gt; /home/fedora/percolator/percolator/src/converters/libs/dll/libtokyocabinet.a<br>
&gt;&gt; -lz -lsqlite3 -Wl,-Bstatic -lkernel32 -luser32 -lgdi32 -lwinspool -lshell32<br>
&gt;&gt; -lole32 -loleaut32 -luuid -lcomdlg32 -ladvapi32<br>
&gt;&gt; /usr/lib/gcc/i686-pc-mingw32/4.5.3/../../../../i686-pc-mingw32/bin/ld:<br>
&gt;&gt; cannot find -lxerces-c<br>
&gt;&gt; /usr/lib/gcc/i686-pc-mingw32/4.5.3/../../../../i686-pc-mingw32/bin/ld:<br>
&gt;&gt; cannot find -lportablexdr<br>
&gt;&gt; /usr/lib/gcc/i686-pc-mingw32/4.5.3/../../../../i686-pc-mingw32/bin/ld:<br>
&gt;&gt; cannot find -lz<br>
&gt;&gt; /usr/lib/gcc/i686-pc-mingw32/4.5.3/../../../../i686-pc-mingw32/bin/ld:<br>
&gt;&gt; cannot find -lsqlite3<br>
&gt;&gt;<br>
&gt;&gt; That is weird cos I &quot;load&quot; all the libraries in the same way and they all<br>
&gt;&gt; the variables content the right paths to the libraries : (for example)<br>
&gt;&gt;<br>
&gt;&gt; Xercesc : /usr/i686-pc-mingw32/sys-root/mingw/lib/libxerces-c.dll.a , XDR :<br>
&gt;&gt; /usr/i686-pc-mingw32/sys-root/mingw/lib/libportablexdr.dll.a<br>
&gt;&gt;<br>
&gt;&gt; This is how I link :<br>
&gt;&gt;<br>
&gt;&gt; #COMPILING SQT2PIN<br>
&gt;&gt; include_directories(. MSToolkit/RAMP MSToolkit )<br>
&gt;&gt; add_executable(sqt2pin Sqt2Pin.cpp )<br>
&gt;&gt; IF(STATIC AND MINGW)<br>
&gt;&gt;   set_property(TARGET sqt2pin PROPERTY LINK_SEARCH_END_STATIC ON)<br>
&gt;&gt;   set_target_properties(sqt2pin PROPERTIES LINK_FLAGS &quot;-Wl,-Bstatic<br>
&gt;&gt; -static-libgcc&quot;)<br>
&gt;&gt; ENDIF()<br>
&gt;&gt; message(STATUS &quot;Xercesc : ${XERCESC_LIBRARIES} , XDR :<br>
&gt;&gt; ${PORTABLEXDR_LIBRARIES}&quot;)<br>
&gt;&gt; target_link_libraries(sqt2pin converters perclibrary_part  MSToolkit RAMP<br>
&gt;&gt; ${XERCESC_LIBRARIES} ${PORTABLEXDR_LIBRARIES} ${TOKYOCABINET_LIBRARIES} )<br>
&gt;&gt;<br>
&gt;&gt; I might  be missing something very stupid because I use the same prodecure<br>
&gt;&gt; to search for the librarys....the FindXXX.cmake macros that are tested and<br>
&gt;&gt; working with other programs.<br>
&gt;&gt;<br>
&gt;&gt; Could it be the include_directories(&quot;library include dir&quot;) which is messing<br>
&gt;&gt; this up? it looks like the linker disregard the path of the library that Im<br>
&gt;&gt; pasinng and looks for -lxerces-c instead. Is that xerces-c defined somehow<br>
&gt;&gt; before?<br>
&gt;<br>
&gt; This happens if the library is considered to be in a &#39;system path&#39; since<br>
&gt; in that case specifying the path is not necessary for the linker to find<br>
&gt; it. However in your specific case it seems like cmake does this even for<br>
&gt; static libraries, which is of course wrong. I&#39;d suggest to file a<br>
&gt; bugreport for this with a small self-contained example.<br>
&gt;<br>
&gt; Andreas<br>
<br>
</div></div>The -l switch of ld is not related to the library&#39;s type, i.e.<br>
shared or static; see ld&#39;s manpage and the following example:<br>
<br>
CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)<br>
PROJECT(STATIC C)<br>
SET(CMAKE_VERBOSE_MAKEFILE ON)<br>
FILE(WRITE ${CMAKE_BINARY_DIR}/f.c &quot;int f(void){return 0;}\n&quot;)<br>
EXECUTE_PROCESS(COMMAND ${CMAKE_C_COMPILER} -c f.c)<br>
EXECUTE_PROCESS(COMMAND ${CMAKE_AR} cr libf.a f.o)<br>
FILE(WRITE ${CMAKE_BINARY_DIR}/main.c &quot;int main(void){return f();}\n&quot;)<br>
ADD_EXECUTABLE(main main.c)<br>
TARGET_LINK_LIBRARIES(main -L${CMAKE_BINARY_DIR} f /usr/lib/libz.a)<br>
<br>
The executable &quot;main&quot; is linked against the static libf.a via the -l<br>
switch. Usually, in particular on ELF systems, ld just prefers shared<br>
libraries with -l unless it is told to not do so, e.g. using -Bstatic.<br>
However, MinGW&#39;s ld behaves differently in this regard; IIRC, it even<br>
prefers static and import libraries to shared ones with the -l switch.<br>
<br>
BTW, /usr/lib/libz.a is converted into -Wl,-Bstatic -lz -Wl,-Bdynamic<br>
due to /usr/lib being a system directory, i.e. CMake performs this -l<br>
conversion of full paths in system directories for static libraries,<br>
too; why should it be called wrong?<br>
<br>
Jose, could you find out which directories CMake considers as system<br>
directories and if these are actually searched implicitly by ld? If<br>
CMake takes /usr/i686-pc-mingw32/sys-root/mingw/lib as system dir,<br>
thus libxerces-c.dll.a --&gt; -lxerces-c, but ld does not search it<br>
without a proper -L switch, the issue would be quite clear. As<br>
a quick workaround, you might use imported targets for the<br>
concerned libraries to avoid the -l conversion, i.e.:<br>
<br>
ADD_LIBRARY(xerces-c STATIC IMPORTED)<br>
SET_TARGET_PROPERTIES(xerces-c PROPERTIES IMPORTED_LOCATION<br>
    /usr/i686-pc-mingw32/sys-root/mingw/lib/libxerces-c.dll.a)<br>
TARGET_LINK_LIBRARIES(... xerces-c ...)<br>
<br>
&#39;hope that helps.<br>
<br>
Regards,<br>
<font color="#888888"><br>
Michael<br>
</font><div><div></div><div class="h5">--<br>
<br>
Powered by <a href="http://www.kitware.com" target="_blank">www.kitware.com</a><br>
<br>
Visit other Kitware open-source projects at <a href="http://www.kitware.com/opensource/opensource.html" target="_blank">http://www.kitware.com/opensource/opensource.html</a><br>
<br>
Please keep messages on-topic and check the CMake FAQ at: <a href="http://www.cmake.org/Wiki/CMake_FAQ" target="_blank">http://www.cmake.org/Wiki/CMake_FAQ</a><br>
<br>
Follow this link to subscribe/unsubscribe:<br>
<a href="http://www.cmake.org/mailman/listinfo/cmake" target="_blank">http://www.cmake.org/mailman/listinfo/cmake</a><br>
</div></div></blockquote></div><br>