Notes |
|
(0028170)
|
Eric NOULARD
|
2012-01-04 15:17
|
|
Hi,
Do other CPack generator exhibit the same behavior?
What about, e.g.
cpack.exe -G ZIP
or
cpack.exe -G TGZ |
|
|
(0028171)
|
Eric NOULARD
|
2012-01-04 15:30
|
|
More questions:
1) Did previous cpack version(s) work for the same project?
2) Which NSIS version are you using?
3) Does this error occurs on plain Windows (not in a VM)?
About the CPackConfig.cmake file:
Why did you enabled DragNDrop generator ?
--> SET(CPACK_GENERATOR "DragNDrop;NSIS")
is it even possible to run this on Windows?
What happen if you
--> SET(CPACK_GENERATOR "NSIS") |
|
|
(0028176)
|
Bastian Angermann
|
2012-01-04 16:11
|
|
The problem also occurs with ZIP and TGZ generators.
The same issue occurs with Cpack 2.8.4
I am using NSIS 2.46
I don't have a plain Windows development rig. I'd have to set up a new machine.
SET(CPACK_GENERATOR "NSIS") has no effect.
CPack is working with the same CMakeLists.txt generating the CPack configuration on MacOs 10.6.8 and different versions of ubuntu.
If I disable building/installing one of the executables, using a conditional ADD_SUBDIRECTORY in the CMakeLists.txt the problem goes away. I am currently trying to narrow down the settings which trigger the issue. |
|
|
(0028183)
|
Eric NOULARD
|
2012-01-04 16:36
|
|
Since you use MinGW Makefile generator
how does
make install
behave?
Does it crash as well?
You can try to narrow down the location of the crash by running:
cpack.exe -G NSIS --debug --verbose
May be you can attach the possibly offending CMakeLists.txt
(the one located inside the conditionnally build subdir)
Or simply verify the install rule of the concerned executable.
Ultimately are your project source available? |
|
|
(0028184)
|
Bastian Angermann
|
2012-01-04 17:30
|
|
Make install succeeds.
I've attached the output of cpack.exe -G NSIS --debug --verbose (cpack_output.txt)
It turns out that there seems to be a confilct between two components. I can enable either component, but not both. I'll attach the CMakeLists.
I ran cpack in gdb, but all i got was this uninformative stack trace:
Program received signal SIGSEGV, Segmentation fault.
0x77c36cc1 in msvcrt!bsearch () from C:\WINDOWS\system32\msvcrt.dll
(gdb) bt
#0 0x77c36cc1 in msvcrt!bsearch () from C:\WINDOWS\system32\msvcrt.dll
#1 0x77c36d22 in msvcrt!getenv () from C:\WINDOWS\system32\msvcrt.dll
0000002 0x05b529f8 in ?? ()
0000003 0x00000000 in ?? ()
(gdb) info threads
* 1 thread 2660.0xdac 0x77c36cc1 in msvcrt!bsearch ()
from C:\WINDOWS\system32\msvcrt.dll |
|
|
(0028191)
|
Eric NOULARD
|
2012-01-05 02:21
|
|
Not really sure what happen there but it looks like
multiple calls to fixup_bundle may generate trouble.
Just to check could you modify or comment your install rules
such that only one call to fixup_bundle is done.
(I know this would may give you unusable installer
I just want to narrow down the problem)
Sidenote, this kind of code may be simplified (noIF needed):
IF(UNIX)
INSTALL(TARGETS simModeler
BUNDLE DESTINATION . COMPONENT Runtime
RUNTIME DESTINATION bin COMPONENT Runtime
)
ELSE(UNIX)
INSTALL(TARGETS simModeler
BUNDLE DESTINATION . COMPONENT Runtime
RUNTIME DESTINATION bin COMPONENT Runtime
)
ENDIF(UNIX) |
|
|
(0028199)
|
Bastian Angermann
|
2012-01-05 15:22
|
|
CPack will not crash if any one of the fixup_bundle calls is commented out.
I'll try to fixup all executables in a single fixup bundle call. |
|
|
(0028200)
|
Eric NOULARD
|
2012-01-05 15:38
|
|
Any chance for you compile a debug build of CMake
in order to be able to get more usable CPack stack trace?
CPack uses DESTDIR install you said that
make install finishes ok
how does?
make DESTDIR=/a/valid/path install |
|
|
(0028201)
|
Eric NOULARD
|
2012-01-05 15:39
|
|
|
|
(0028203)
|
Bill Hoffman
|
2012-01-05 16:16
|
|
Can you attach a complete project that shows the crash? One zip file with all the sources and CMakeLists.txt files. Where all we need to do is run cmake, make, and cpack to get the crash? |
|
|
(0028206)
|
Bastian Angermann
|
2012-01-06 11:09
|
|
The stack trace was produced by a debug build.
Interestingly, CPack will generate a Package if I set breakpoints on entering and exiting cmMakeFile::ReadListFile, when I do this I get an error window from link.exe "This application failed to start because mspds71.dll was not found. Re-installing the application may fix the problem". This message shows up about a dozen times, somewhere below the 2nd recursive call of ReadListFile on BundleUtils for one of the project components which seemed be unrelated before.
I'd have to get approval to attach the complete source. And even then I am not sure it would be worth your while, the project has a large number of dependencies which would have to be built before. I could try to provide a package that bundles most of the dependencies. This would be something that would be useful anyway, but this might take some time. |
|
|
(0028207)
|
Bill Hoffman
|
2012-01-06 14:01
|
|
I just noticed you are debugging with gdb. What happens if you use an official CMake release from Kitware. Maybe this is a build issue.
-Bill |
|
|
(0028208)
|
Bastian Angermann
|
2012-01-06 14:41
|
|
I used the official CMake releases 2.8.4 and 2.8.7 before I compiled the debug version. |
|
|
(0028209)
|
Bill Hoffman
|
2012-01-06 15:42
|
|
Maybe try the free visual studio compiler. It might have a better debugger. |
|
|
(0030347)
|
David Cole
|
2012-08-11 21:09
|
|
Sending old, never assigned issues to the backlog.
(The age of the bug, plus the fact that it's never been assigned to anyone means that nobody is actively working on it...)
If an issue you care about is sent to the backlog when you feel it should have been addressed in a different manner, please bring it up on the CMake mailing list for discussion. Sign up for the mailing list here, if you're not already on it: http://www.cmake.org/mailman/listinfo/cmake [^]
It's easy to re-activate a bug here if you can find a CMake developer who has the bandwidth to take it on, and ferry a fix through to our 'next' branch for dashboard testing.
|
|
|
(0041955)
|
Kitware Robot
|
2016-06-10 14:28
|
|
Resolving issue as `moved`.
This issue tracker is no longer used. Further discussion of this issue may take place in the current CMake Issues page linked in the banner at the top of this page. |
|