[CMake] cmake 2.6 and find_library with MinGW generator

Christian Ehrlicher Ch.Ehrlicher at gmx.de
Wed May 21 03:43:44 EDT 2008


> Von: Hendrik Sattler
> Christian Ehrlicher schrieb:
> >> Von: Hendrik Sattler
> >> Christian Ehrlicher schrieb:
> >>     
> >>> during your new warning when mixing libs in target_link_libraries 
> >>> (CMP0003) I changed target_link_libraries(foo ws2_32) to
> >>>
> >>> find_library(WS2_32_LIBRARY ws2_32)
> >>> target_link_libraries(foo ${WS2_32_LIBRARY})
> >>>
> >>> but now cmake finds ws2_32.dll in system32 instead the correct one 
> >>> (ws2_32.dll.a / ws2_32.a) in mingw dir.
> >>>       
> >> Set the LIB environment variable to the MinGW lib dir. While you are at
> >> it, do the same for INCLUDE.
> >> This is comparable to the setup for cl.
> >>
> >>     
> > Also they solution is clear I don't like it. MinGW doesn't care about
> LIB (otherwise it wouldn't link against ws2_32.a) so why should cmake do in
> this case?
> > The problem is the new warning - it suggest that a simple find_library
> would do the job but it doesn't - it breaks compilation. Looks like this
> warning is the first one which I'll disable by default. Maybe also in kde4/win
> because it's imho useless when linking against system libs (on windows).
> >   
> Did find_library in CMake 2.4 find he correct one?
Don't know but don't think so - I completly switched to 2.6 a while ago.

> I also think that this could be improved: for "MinGW Makefiles" 
> generator, cmake could get the base MinGW directory and add
> the lib/ and include/ subdirs to the front of default paths. Then, 
> find_library() would magically work again.
> Do you want to create a bug tracker entry for that issue?
I will - just wanted to discuss it here to see if you maybe can convince me that's the correct behaviour for mingw :)

Christian
-- 
Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! 
Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer


More information about the CMake mailing list