[CMake] Win32 linker line problems...

[David Cole]

Are you getting linker warning LNK4098? If so, read over this page on 
MSDN; it's by far the most illuminating data I've ever run across about 
libs and the /M* compiler flags. You have to set up the nodefaultlib 
flags to ignore *all other 5 runtime libs* that you don't want to 
completely eliminate this warning.

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vccore/html/LNK4098.asp

Are there any 3rd party libs that you are linking in binary form that 
might have a conflicting need for a different runtime lib than what you 
are specifying?


HTH,
David


Lars Pechan wrote:

> Hi Bill,
> I have already set the compiler flags to use MTd and it doesn't help.
>
> There is a particular directory in the tree containing about 100 cpp 
> files that have functions from LIBCMT.LIB copied into the individual 
> object files. I've been trying to understand why but I'm afraid I've 
> drawn a blank. I thought it might be a dodgy '#pragma' or a 
> particlular MS header or something but I haven't been able to find 
> anything. There some info from MS  about this happening when using MFC 
> but MFC isn't even used in that directory. Everywhere else the C and 
> C++ files compile fine. (The same compiler flags are used practically 
> everywhere.)
>
> If there are any MS Linker gurus on the list I'd be most grateful for 
> a pointer. (operator new is listed as a COMDAT in the object files).
>
> Thanks anyway,
>
> /Lars
>
> On 20/04/2005, at 5:50 AM, William A. Hoffman wrote:
>
>> Actually, I think if you made the correct changes to CMAKE_C_FLAGS, 
>> CMAKE_C_FLAGS_[DEBUG...]
>> and to CMAKE_CXX flags, it should work.  See 
>> Modules/Platforms/Windows-cl.cmake.
>>
>>
>> If you change these flags:
>>
>>   SET (CMAKE_CXX_FLAGS_INIT "/W3 /Zm1000 /EHsc /GR")
>>   SET (CMAKE_CXX_FLAGS_DEBUG_INIT "/MDd /Zi /Od /RTC1")
>>   SET (CMAKE_CXX_FLAGS_MINSIZEREL_INIT "/MD /O1 /D NDEBUG")
>>   SET (CMAKE_CXX_FLAGS_RELEASE_INIT "/MD /O2 /D NDEBUG")
>>   SET (CMAKE_CXX_FLAGS_RELWITHDEBINFO_INIT "/MD /Zi /O2 /D NDEBUG")
>>   SET (CMAKE_C_FLAGS_INIT "/W3 /Zm1000")
>>   SET (CMAKE_C_FLAGS_DEBUG_INIT "/MDd /Zi /Od /GZ")
>>   SET (CMAKE_C_FLAGS_MINSIZEREL_INIT "/MD /O1 /D NDEBUG")
>>   SET (CMAKE_C_FLAGS_RELEASE_INIT "/MD /O2 /D NDEBUG")
>>   SET (CMAKE_C_FLAGS_RELWITHDEBINFO_INIT "/MD /Zi /O2 /D NDEBUG")
>>
>> To all use /MTd, then you will not need to mess with the linker options.
>>
>> -Bill
>>
>>
>> At 02:13 AM 4/19/2005, Lars Pechan wrote:
>>
>>> Hello,
>>> I use CMake in a project where I build lots of static libs that are 
>>> later linked together to an app. In order to check this app for 
>>> leaks I use VisualLeakDetector 
>>> (http://www.codeproject.com/useritems/visualleakdetector.asp) which 
>>> requires the app to be compiled with /MTd. This causes some problems 
>>> in a few places and I end up with multiply defined stuff from the C 
>>> runtime libs so I set up
>>>
>>> CMAKE_EXE_LINKER_FLAGS_DEBUG
>>> CMAKE_MODULE_LINKER_FLAGS_DEBUG
>>> CMAKE_SHARED_LINKER_FLAGS_DEBUG
>>>
>>> to all be "/debug /NODEFAULTLIB:LIBCMT.LIB /FORCE:MULTIPLE".
>>>
>>> This works fine when using the NMake Makefiles generator. 
>>> Unfortunately, when using the "Visual Studio 7.NET 2003" generator 
>>> these settings seem to be ignored. In Visual Studio I can't see my 
>>> flags having any effect at all when I look in the linker properties. 
>>> Not sure why but I was under the impression that these flags should 
>>> just be added to the linker command line options?
>>>
>>> I set the variables in a cache file that loads when the 
>>> build-directory is generated. I can see the vars from CMakeSetup.
>>>
>>> I've seen the same behaviour on CMake 2.0.6, CMakeCVS-20050330 and 
>>> CMakeCVS-20050415.
>>>
>>> Thanks for your help.
>>>
>>> /Lars
>>>
>>>
>>> _______________________________________________
>>> CMake mailing list
>>> CMake at cmake.org
>>> http://www.cmake.org/mailman/listinfo/cmake
>>
>>
>
> _______________________________________________
> CMake mailing list
> CMake at cmake.org
> http://www.cmake.org/mailman/listinfo/cmake
>