Hi,
Using CMake and Visual Studio 2010exp to build DLLs for use in Wireshark we are
seeing inconsistent results. On all our computers the build verdict is
successful. Unfortunately it appears that the DLLs are broken when built on
some computers - the DLLs can not be loaded.
**** Tool setup ****
CMake version: 2.8.7
Visual Studio Version: 2010 express,
Cygwin and Msys shells
I have compared the build output from a computer that builds working DLLs with
the output from a build resulting in broken DLLs.
**** The build output from the "corrupt" builds: ****
Manifest:
C:\Program Files\Microsoft SDKs\Windows\v7.0A\bin\mt.exe /nologo /verbose
/out:"csr_log_proto_ws_1_2_0.dir\Debug\csr_log_proto_ws_1_2_0.dll.embed.manifest"
/manifest
csr_log_proto_ws_1_2_0.dir\Debug\csr_log_proto_ws_1_2_0.dll.intermediate.manifest
All outputs are up-to-date.
LinkEmbedManifest:
All outputs are up-to-date.
csr_log_proto_ws_1_2_0.vcxproj ->
S:\p4\synergy\frw\main\output\vs10\plugin\Debug\csr_log_proto_ws_1_2_0.dll
FinalizeBuildStatus:
Deleting file
"csr_log_proto_ws_1_2_0.dir\Debug\csr_log_proto_ws_1_2_0.unsuccessfulbuild".
Touching
"csr_log_proto_ws_1_2_0.dir\Debug\csr_log_proto_ws_1_2_0.lastbuildstate".
**** The build output from the "functional" builds: ****
Manifest:
C:\Program Files\Microsoft SDKs\Windows\v7.0A\bin\mt.exe /nologo /verbose
/out:"csr_log_proto_ws_1_2_0.dir\Debug\csr_log_proto_ws_1_2_0.dll.embed.manifest"
/manifest
csr_log_proto_ws_1_2_0.dir\Debug\csr_log_proto_ws_1_2_0.dll.intermediate.manifest
C:\Program Files\Microsoft SDKs\Windows\v7.0A\bin\rc.exe /nologo
/fo"csr_log_proto_ws_1_2_0.dir\Debug\csr_log_proto_ws_1_2_0.dll.embed.manifest.res"
csr_log_proto_ws_1_2_0.dir\Debug\csr_log_proto_ws_1_2_0_manifest.rc
LinkEmbedManifest:
C:\Program Files\Microsoft Visual Studio 10.0\VC\bin\link.exe
/ERRORREPORT:QUEUE
/OUT:"S:\p4\synergy\frw\main\output\vs10\plugin\Debug\csr_log_proto_ws_1_2_0.dll"
/INCREMENTAL /NOLOGO kernel32.lib user32.lib gdi32.lib winspool.lib
shell32.lib ole32.lib oleaut32.lib uuid.lib comdlg32.lib advapi32.lib
"..\..\..\..\..\..\tools\wireshark\wireshark-win32-libs\glib\lib\glib-2.0.lib"
"..\..\..\..\..\..\tools\wireshark\wireshark-1.2.0\epan\libwireshark.lib"
/MANIFEST
/ManifestFile:"csr_log_proto_ws_1_2_0.dir\Debug\csr_log_proto_ws_1_2_0.dll.intermediate.manifest"
/MANIFESTUAC:"level='asInvoker' uiAccess='false'" /DEBUG
/PDB:"S:\p4\synergy\frw\main\output\vs10\plugin\Debug\csr_log_proto_ws_1_2_0.pdb"
/SUBSYSTEM:CONSOLE /STACK:"10000000" /TLBID:1 /DYNAMICBASE /NXCOMPAT
/IMPLIB:"S:/p4/synergy/frw/main/output/vs10/lib/Debug/csr_log_proto_ws_1_2_0.lib"
/MACHINE:X86 /DLL
csr_log_proto_ws_1_2_0.dir\Debug\csr_log_proto_ws_1_2_0.dll.embed.manifest.res
"csr_log_proto_ws_1_2_0.dir\Debug\packet-utils.obj"
csr_log_proto_ws_1_2_0.dir\Debug\csr_proto_plugin.obj
"csr_log_proto_ws_1_2_0.dir\Debug\packet-bccmd.obj"
"csr_log_proto_ws_1_2_0.dir\Debug\packet-bcsp-slip.obj"
"csr_log_proto_ws_1_2_0.dir\Debug\packet-bcsp.obj"
"csr_log_proto_ws_1_2_0.dir\Debug\packet-hqcmd.obj" /machine:X86 /debug
Creating library
S:/p4/synergy/frw/main/output/vs10/lib/Debug/csr_log_proto_ws_1_2_0.lib and
object S:/p4/synergy/frw/main/output/vs10/lib/Debug/csr_log_proto_ws_1_2_0.exp
csr_log_proto_ws_1_2_0.vcxproj ->
S:\p4\synergy\frw\main\output\vs10\plugin\Debug\csr_log_proto_ws_1_2_0.dll
FinalizeBuildStatus:
Deleting file
"csr_log_proto_ws_1_2_0.dir\Debug\csr_log_proto_ws_1_2_0.unsuccessfulbuild".
Touching
"csr_log_proto_ws_1_2_0.dir\Debug\csr_log_proto_ws_1_2_0.lastbuildstate".
**** Steps performed on both computers ****
- Checkout source from our source control server
- Create a new (empty) output directory
- Generate a build system (cmake -G "Visual Studio 10" <path to
CMakeLists-file>)
- Build code (cmake -build .)
Considering that I am performing a completely clean build I am a bit puzzled
that the "corrupt" builds reach the conclusion that some part of the build is
"up-to-date" in the "manifest" and "LinkEmbedManifest" stages.
We have tried to force a no-parallel build by specifying maxcpucount=1 to VS,
but the "corrupt" build still reach the conclusion that some parts are
up-to-date and there for skips the resource compiler.
I see the same result building from command line and when building from the
IDE. The "corrupt" computer can however produce working DLL's if the
configuration is set to "Release" instead of "Debug" (currently "debug" is our
default configuration)
Currently I have "functional" builds from two different computers and "corrupt"
builds from 2 other computers. It should be noted that the two "corrupt"
computers can produce functional DLLs with VS2008.
Am I doing something wrong? Is there something that I need to give special
attention when building DLL's with the CMake + VS2010 combination? Is there a
CMake option to force the environment to be completely clean during the build
process?
Has anyone encountered similar issues? I understand that this can easily be a
Visual Studio issue (configuration and/or use of VS)
I am quite puzzled as to why I get working DLLs and corrupt DLLs executing
identical operations on different computers. Any guidance will be greatly
appreciated.
We have tried the following setups as well:
CMake version: 2.8.7
Visual Studio Version: 2010 express SP1,
CMake version: 2.8.8
Visual Studio Version: 2010 express,
For completeness; the error I get in Wireshark is a pop-up message saying:
Couldn't load module C:\Program
Files\Wireshark\plugins\1.2.0\csr_log_proto_ws_1_2_0.dll: `C:\Program
Files\Wireshark\plugins\1.2.0\csr_log_proto_ws_1_2_0.dll': The parameter is
incorrect.
And the information from the debugger is:
SXS: RtlCreateActivationContext() failed 0xc000000d
LDR: LdrpWalkImportDescriptor() failed to probe C:\Program
Files\Wireshark\plugins\1.2.0\csr_log_fw_proto_ws_1_2_10.dll for its manifest,
ntstatus 0xc000000d
Best regards,
Casper Madsen
Senior Engineer, Software
Cambridge Silicon Radio Ltd.
Niels Jernes Vej 10
9220 Aalborg Øst
Denmark
Tel: +45 99324122
Fax: +45 99324101
Member of the CSR plc group of companies. CSR plc registered in England and
Wales, registered number 4187346, registered office Churchill House, Cambridge
Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom
More information can be found at www.csr.com. Follow CSR on Twitter at
http://twitter.com/CSR_PLC and read our blog at www.csr.com/blog
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
