[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