<extended from my short suggestion on IRC yesterday> some time ago i was working with some people finding errors on their software (built with MSVC), i was surprised how fast they fix issues in release builds (*cough* in most cases), by just knowing the faulting offset in the executable, with or without reproducing the bug locally.
the reason for that is that MSVC compiles the debug symbols in external files (.PDB). so while they give users the release build, they also have the release build, but with debug symbol files. i think this is a much wiser distribution scheme debug symbol wise, compared to what GCC does by default. as i said on IRC, GDB also supports it and i have tested it with MINGW 4.9.2. it works for me, as long as the debug files are in the same folder (can't get "set debug-file-directory X" to work). https://sourceware.org/gdb/onlinedocs/gdb/Separate-Debug-Files.html GDB can also perform a bunch of gymnastics to load DLL symbols, with add-symbol-file, but for that one needs to know at which address the binary will be allocated in the process space. more awkward, but it also works as i have tested add-symbol-file as well. CMAKE wise, i see they support -DCMAKE_BUILD_TYPE=RelWithDebInfo but i haven't tested that. of course, here we are only interested to build some libraries (e.g. libgit2) and the main executable with debug symbols (-g), store the debug symbols in separate files and strip them from the binaries targeting the user. i don't see this approach working for Qt as they already have "d" and "non-d" files and there is probably more than just debug symbols in the "d" version, but everything else which is built from source *should* work. so, Dirk if you implement this with scripts on your end and next to a release Win32 installer upload a zip with debug symbols for our main faulting module candidates (e.g. subsurface.exe, libgit2.dll, etc), we can actually debug a release build much easier. let me know if you are interested and i can help with examples. lubomir -- _______________________________________________ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
