[CMake] Problem with CMAKE_SHARED_LIBRARY_SUFFIX on windows

Bill Hoffman bill.hoffman at kitware.com
Wed Apr 26 10:20:05 EDT 2006


See the SET_TARGET_PROPERTIES command.
You can set the prefix or postfix on a per target basis.
You should never change these variables.

-Bill


At 09:35 AM 4/26/2006, Ian.Appru at ubs.com wrote:
>After a bit more investigation - the problem is that setting CMAKE_SHARED_LIBRARY_SUFFIX to .xll causes cmake to forget that ".dll" is still a valid library name on windows.
> 
>My workaround: I have discovered a new variable CMAKE_EXTRA_LINK_EXTENSIONS which enables me to remind cmake that .dll is still valid, so I have to use both together -
> 
>SET(CMAKE_SHARED_LIBRARY_SUFFIX ".xll")
>SET(CMAKE_EXTRA_LINK_EXTENSIONS ".dll")
>This fixes the link name problem outlined previously and means dependencies work also.
>
>A better solution might be for the CMake module Windows.cmake to define
>    SET(CMAKE_EXTRA_LINK_EXTENSIONS ".dll")
> 
>so that there is no chance of cmake forgetting that ".dll" is still valid if I redifine CMAKE_SHARED_LIBRARY_SUFFIX.
> 
>- Ian
> 
>
>----------
>From: cmake-bounces+ian.appru=ubs.com at cmake.org [mailto:cmake-bounces+ian.appru=ubs.com at cmake.org] On Behalf Of Appru, Ian
>Sent: 26 April 2006 13:14
>To: cmake at cmake.org
>Subject: [CMake] Problem with CMAKE_SHARED_LIBRARY_SUFFIX on windows
>
>Hi 
>
>I have come across a problem when using the cmake version 2.5-20060419 with the Visual Studio 7 .NET 2003 generator. 
>
>When building an C++ Excel add-in ie with CMAKE_SHARED_LIBRARY_SUFFIX set to ".xll" and linking to standard dll's, the optimized libs set in TARGET_LINK_LIBRARIES end up with the format MyLib.dll.lib instead of MyLib.lib
>
>The debug libs are set correctly to MyLib-D.lib 
>
>--- 
>As a bit of extra info - hardwiring the linked library to the lib suffix - ie changing 
>TARGET_LINK_LIBRARIES(TestLibA 
>        optimized TestLib debug TestLib-D ) 
>
>to 
>
>TARGET_LINK_LIBRARIES(TestLibA 
>        optimized TestLib.lib debug TestLib-D.lib) 
>
>fixes the problem, but then of course dependency information is lost. 
>
>Looking at the code, a fix looks non-trivial but if you have any pointers, would be apreciated. 
>
>Regards 
>Ian 
>
>
>
>
>Visit our website at http://www.ubs.com
>
>This message contains confidential information and is intended only 
>for the individual named.  If you are not the named addressee you 
>should not disseminate, distribute or copy this e-mail.  Please 
>notify the sender immediately by e-mail if you have received this 
>e-mail by mistake and delete this e-mail from your system.
>
>E-mail transmission cannot be guaranteed to be secure or error-free 
>as information could be intercepted, corrupted, lost, destroyed, 
>arrive late or incomplete, or contain viruses.  The sender therefore 
>does not accept liability for any errors or omissions in the contents 
>of this message which arise as a result of e-mail transmission.  If 
>verification is required please request a hard-copy version.  This 
>message is provided for informational purposes and should not be 
>construed as a solicitation or offer to buy or sell any securities or 
>related financial instruments.
>_______________________________________________
>CMake mailing list
>CMake at cmake.org
>http://www.cmake.org/mailman/listinfo/cmake 



More information about the CMake mailing list