On 12 November 2017 at 09:22, Dirk Hohndel <[email protected]> wrote: > > On Nov 11, 2017, at 10:53 PM, Stefan Fuchs <[email protected]> wrote: > > I would keep posting the subsurface.exe > When creating my own builds and testing I very often just replace the exe to > test s.th. because it's faster... > > > Either way is no problem. I need to figure out how to post better > explanations there, but that I'm pretty sure is easy to do. >
i would like to bring something up again - 3rd time is charm. when a user reports a crash at some offset in the subsurface.exe, there is really no straightforward way of debugging the crash. i know that "real man" don't use debug symbols and dream in x86...but how about we facilitate this finally for the Windows build? :-) 1) use "RelWithDebInfo": cmake <commands> -DCMAKE_BUILD_TYPE=RelWithDebInfo (subsurface.exe is created with debug symbols but it's not linked to the debug version of Qt) 2) objcopy --only-keep-debug subsurface.exe subsurface.exe.debug (copy the debug symbols to the .debug file) 3) objcopy --strip-debug --strip-unneeded subsurface.exe (strip the debug symbols from the .exe) 4) objcopy --add-gnu-debuglink=subsurface.exe.debug subsurface.exe (apply the debuglink thingy) 5) upload subsurface.exe.debug next to the Windows build (~70MB for me) in the Github release results: - subsuface.exe is still a stripped down release build - gdb subsuface.exe reads debug symbols from the .debug file if it's in the same path as the .exe! - profit? maybe i can give it a try by just creating a new Github branch and messing with the Travis build as i don't have a MXE setup? ACK/NAK? lubomir -- _______________________________________________ subsurface mailing list [email protected] http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
