[CMake] CMake 2.4.7: Generator Visual Studio 7 .NET 2003 seems to ignore certain LINK_FLAGS properties (worked in 2.4.6)
Hello there, after upgrading from CMake 2.4.6 to 2.4.7, the previously working build of our software project failed. The failures were caused by missing linker flags in Visual Studio .NET projects that have been specified in the CMakeLists.txt files using set_target_properties(mytarget PROPERTIES LINK_FLAGS myflags) The missing flags are: /DEF:module definition file (This is completely ignored, resulting in missing DLL entry points.) /DLL /NOENTRY (This combination is required to build a resource-only .exe file for inclusion in a Windows Installer setup. However, only /NOENTRY shows up in the Visual Studio project - and is ignored by the linker since /DLL is missing, resulting in a link error.) If those flags have been blocked intentionally, I would be interested to know the reason, and how to have them generated with 2.4.7 (since they are obviously required at times). Otherwise it would be vital to have them work again in Visual Studio .NET - as of now, I'm forced to revert to 2.4.6, which is a pity, since 2.4.7 provides native support for precompiled headers in Visual Studio... BTW: The NMake Makefiles Generator still accepts those LINK_FLAGS, and the build using Makefiles still works. Best regards, Gerhard ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake 2.4.7: Generator Visual Studio 7 .NET 2003 seems to ignore certain LINK_FLAGS properties (worked in 2.4.6)
Gerhard Grimm wrote: Hello there, after upgrading from CMake 2.4.6 to 2.4.7, the previously working build of our software project failed. The failures were caused by missing linker flags in Visual Studio .NET projects that have been specified in the CMakeLists.txt files using set_target_properties(mytarget PROPERTIES LINK_FLAGS myflags) The missing flags are: /DEF:module definition file (This is completely ignored, resulting in missing DLL entry points.) /DLL /NOENTRY (This combination is required to build a resource-only .exe file for inclusion in a Windows Installer setup. However, only /NOENTRY shows up in the Visual Studio project - and is ignored by the linker since /DLL is missing, resulting in a link error.) If those flags have been blocked intentionally, I would be interested to know the reason, and how to have them generated with 2.4.7 (since they are obviously required at times). Otherwise it would be vital to have them work again in Visual Studio .NET - as of now, I'm forced to revert to 2.4.6, which is a pity, since 2.4.7 provides native support for precompiled headers in Visual Studio... BTW: The NMake Makefiles Generator still accepts those LINK_FLAGS, and the build using Makefiles still works. Bummer! Sounds like a bug in 2.4.7 That is why I do the release candidates... Oh well. Can you provide a small example that shows this problem? -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
AW: [CMake] CMake 2.4.7: Generator Visual Studio 7 .NET 2003 seems to ignore certain LINK_FLAGS properties (worked in 2.4.6)
Hi Bill,
here's a minimal example, consisting of three files.
source.c:
-
#include stdio.h
void MyExport1(void)
{
puts(MyExport1);
}
void MyExport2(void)
{
puts(MyExport2);
}
-
source.def:
-
EXPORTS
MyExport1
MyExport2
-
CMakeLists.txt:
-
project(MyProject)
add_library(MyLib SHARED source.c)
set_target_properties(MyLib PROPERTIES LINK_FLAGS
/DEF:${CMAKE_CURRENT_SOURCE_DIR}/source.def)
-
When using the 2.4.7 Visual Studio .NET generator, the build will succeed, but
the resulting MyLib.dll will not export any symbols, since the /DEF:...
flag is missing in the project (reverting to 2.4.6 would fix this).
Using the NMake makefiles generator, the /DEF:... flag will be passed to the
linker, and voilà - we have exports.
Thank you for your attention!
Best regards,
Gerhard
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: AW: [CMake] CMake 2.4.7: Generator Visual Studio 7 .NET 2003 seems to ignore certain LINK_FLAGS properties (worked in 2.4.6)
Gerhard Grimm wrote:
Hi Bill,
here's a minimal example, consisting of three files.
source.c:
-
#include stdio.h
void MyExport1(void)
{
puts(MyExport1);
}
void MyExport2(void)
{
puts(MyExport2);
}
-
source.def:
-
EXPORTS
MyExport1
MyExport2
-
CMakeLists.txt:
-
project(MyProject)
add_library(MyLib SHARED source.c)
set_target_properties(MyLib PROPERTIES LINK_FLAGS
/DEF:${CMAKE_CURRENT_SOURCE_DIR}/source.def)
-
When using the 2.4.7 Visual Studio .NET generator, the build will succeed, but the resulting
MyLib.dll will not export any symbols, since the /DEF:... flag is missing
in the project (reverting to 2.4.6 would fix this).
Using the NMake makefiles generator, the /DEF:... flag will be passed to the
linker, and voilà - we have exports.
OK, so I can reproduce the problem, and I will fix it. However, the
reason you are alone here is that you are not really using cmake correctly.
You can just add the .def as one of your sources and cmake knows what to
do with it. As you stated before the /NOENTRY works.
So, the following should be what you want. (The SHARED option will make
sure that /DLL is used as a flag)
add_library(MyLib SHARED source.c source.def)
set_target_properties(MyLib PROPERTIES LINK_FLAGS /NOENTRY)
-Bill
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
AW: AW: [CMake] CMake 2.4.7: Generator Visual Studio 7 .NET 2003 seems to ignore certain LINK_FLAGS properties (worked in 2.4.6)
Hi Bill, thanks for your hints. The /DEF problem is fixed now. However, changing the resource container's target type from executable to library (to avoid passing the /DLL flag explicitly) raised another problem: The resource container (which BTW is not the target from my previous example, it only contains resources and has no exports) is added as dependency to another library target using add_dependencies(OtherLibrary ResourceContainer) [The reason for this is the creation of a header file by a custom command when building the resource container. This header file contains resource IDs and is needed when building the OtherLibrary.] Since the ResourceContainer is now considered a library by Visual Studio, it attempts to link the OtherLibrary with it by adding a non-existing import library to the OtherLibrary's linker command line, although this is mentioned nowhere in the generated project file. I'll try to build a dummy import library for the ResourceContainer... Best regards, Gerhard -Ursprüngliche Nachricht- Von: Bill Hoffman [mailto:[EMAIL PROTECTED] Gesendet: Dienstag, 31. Juli 2007 16:33 An: Gerhard Grimm Cc: cmake@cmake.org Betreff: Re: AW: [CMake] CMake 2.4.7: Generator Visual Studio 7 .NET 2003 seems to ignore certain LINK_FLAGS properties (worked in 2.4.6) OK, so I can reproduce the problem, and I will fix it. However, the reason you are alone here is that you are not really using cmake correctly. You can just add the .def as one of your sources and cmake knows what to do with it. As you stated before the /NOENTRY works. So, the following should be what you want. (The SHARED option will make sure that /DLL is used as a flag) add_library(MyLib SHARED source.c source.def) set_target_properties(MyLib PROPERTIES LINK_FLAGS /NOENTRY) -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
AW: AW: AW: [CMake] CMake 2.4.7: Generator Visual Studio 7 .NET 2003 seems to ignore certain LINK_FLAGS properties (worked in 2.4.6)
Hi Bill, I'm using the term resource container for a Win32 DLL containing no executable code but only resources (in our case icons or messages texts for the Windows event log). To build it, one needs to pass the /NOENTRY flag to the linker. Since my last message, I have managed to solve the problem of Visual Studio wanting an import library for it as result of another target's dependency on the resource DLL. Adding an empty .def file to the DLL's sources made the linker create a dummy import library that did the trick. It might be a clumsy solution, but it works for us and I see no point in bothering you any longer. At last, we can start using CMake 2.4.7 tomorrow :-) Thanks again for your help and patience! Best regards, Gerhard -Ursprüngliche Nachricht- Von: Bill Hoffman [mailto:[EMAIL PROTECTED] Gesendet: Dienstag, 31. Juli 2007 18:17 An: Gerhard Grimm Cc: Bill Hoffman; cmake@cmake.org Betreff: Re: AW: AW: [CMake] CMake 2.4.7: Generator Visual Studio 7 .NET 2003 seems to ignore certain LINK_FLAGS properties (worked in 2.4.6) Gerhard Grimm wrote: Hi Bill, thanks for your hints. The /DEF problem is fixed now. However, changing the resource container's target type from executable to library (to avoid passing the /DLL flag explicitly) raised another problem: The resource container (which BTW is not the target from my previous example, it only contains resources and has no exports) is added as dependency to another library target using add_dependencies(OtherLibrary ResourceContainer) [The reason for this is the creation of a header file by a custom command when building the resource container. This header file contains resource IDs and is needed when building the OtherLibrary.] Since the ResourceContainer is now considered a library by Visual Studio, it attempts to link the OtherLibrary with it by adding a non-existing import library to the OtherLibrary's linker command line, although this is mentioned nowhere in the generated project file. I'll try to build a dummy import library for the ResourceContainer... OK, you lost me, I have no idea what a ResourceContainer is... If you could give a complete example that shows your problem I might be able to help. We have lots of Qt based projects that generate .h files with custom commands. As long as the .h files are in your source list things should work. -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
