Debugging release builds on Win32

[Lubomir I. Ivanov]

On 27 September 2015 at 13:50, Dirk Hohndel <dirk at hohndel.org> wrote:
> On Thu, Sep 24, 2015 at 08:08:43AM -0700, Dirk Hohndel wrote:
>> >
>> > 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.
>>
>> I'm definitely interested. Given how fragile this has been lately I'm
>> freaked out that I might once again break things, though.
>
> I'd still like to try this, though. :-)

let me know if you want me to start explaining how i got it to work.
i can also join IRC this afternoon GMT.

>
>> The crashes in libgit2 especially are weird and annoying.
>> I might point out (cough, cough) that I begged and begged people
>> to actually test this and basically no one did (well, 20 logins were
>> created prior to the beta, and 10 of them were used exactly once
>> or twice). Whatever, water under the bridge.
>>
>> At this stage I'm a long way away from being comfortable releasing
>> what we have as 4.5. Which means we have time to play with this idea
>
> BTW, while flying to Bonaire I tried to build at least Subsurface natively
> under Windows (i.e., I grabbed all the libraries and header files from my
> cross build and wanted to try to build the app itself under Windows so
> that I have a much faster and smoother "edit, compile, test" cycle when
> working on Windows bugs. Right now this is a seriously messed up process...
>
> But I could get cmake to be create Makefiles that I could then run. So I'm
> missing some magic incantation here.
>
> I run this under a bash style shell. Maybe that's my problem?
>
> I create the Makefile with
>
> cmake -G "MinGW Makefiles"
>
> (which moron came up with the idea to have a SPACE in that argument)
>
> And then when I call make it tells me "cmd.exe not found". If I make sure
> that it finds cmd.exe, it then simply opens an interactive shell instead
> of running anything in it. Umm.
>
> Suggestions? How do you run this, Lubomir?
>

this is the same argument that i use:
cmake -G "MinGW Makefiles"

but i also have the MSYS(-GIT) shell executables present in PATH i.e. sh.exe.
this creates an interesting situation...

the cmake people suggest to use -G "MSYS Makefiles" if you have sh.exe in PATH.
BUT most of the libraries simply fail to build with "MSYS Makefiles"
for various reasons, so i have to use "MinGW Makefiles".

for that to work, everytime i call cmake i hide/rename sh.exe to
something like sh.ex_, otherwise cmake says something in the lines of
"ERROR: sh.exe present in PATH! please use "MSYS Makefiles".

cmd.exe is a very important part of Windows and should be present in
<Drive>:\Windows\System32 (e.g. on Windows 7).
my version of cmake here is 3.2.0-rc2 and it has no problem finding cmd.exe.

actually...System32 is in PATH so calling cmd.exe from *anywhere*
should work. e.g.
Windows Key + R -> type cmd.exe.

if cmd.exe is indeed present, cmake must be using a really
bogus/stupid way of finding where it is or somehow something could be
removing System32 from PATH:
before calling make you can check PATH by doing a:

> set PATH
> make

you can also call it again:

> set PATH
to see if the makefile itself isn't modifying PATH for some very odd reason...

lubomir
--