On 09/08/2016 08:23 PM, David Wohlferd wrote:
On 9/8/2016 10:36 AM, Hugo Beauzée-Luyssen wrote:
This only happens when building with -lwindowsapp (see another patch of
mine). When building with the default -lkernel32, all is good, since
kernel32.lib contains GetStartupInfo.
windowsapp.lib, on the other hand, doesn't; which makes sense since the
symbol is forbidden.
Since the issue only happens when building test program within
configure, it seemed ok to add a stub for it.


I'm not opposed to the idea of a stub for GetStartupInfo.  I assume your
plan is to add it to libwindowsapp.a?  I'm guessing the idea is we want
to avoid having to customize the startup code and that sounds like a
good idea.

I'm also thinking some comments to explain what is going on for future
maintainers might be a good idea.  Cuz this is gonna look a bit odd (ie
why are we calling a function that doesn't do anything?).

If the expectation is that the code never gets called, it may even make
sense to have the stub call abort() (or its winstore-appropriate
equivalent) instead of the memset.  Configure doesn't actually run any
of the programs it builds, does it?

dw

------------------------------------------------------------------------------
_______________________________________________
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Hm, it seems my patch didn't make it to the mailing list...
Hopefully this one will go through!
------------------------------------------------------------------------------
_______________________________________________
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Reply via email to