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
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
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
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
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
