#6907 SCUMMVM: scummvm -v returns nothing

[zanac]

Version: buildbot, in archive directory name - mingw-w64-master-51e5baa4
How reproduse: type "scummvm -v" in terminal
OS: Windows XP x64

[George Kormendi]

Same problem, Daily build command line options -v, or -t is working, but compiled version is simple run the GUI.

my compile commands (MinGW):
configure --enable-all-engines
make

OS: Windows 7 x32

[clone2727]

"-mwindows" needs to be removed from sdl-config.

[George Kormendi]

"-mwindows" removed from sdl-config. Command line -v or -t is still not working, just run the GUI :(
How reproduse: type scummvm -v >version.txt

Source:1.8.0git latest
GCC v4.6.2
OS: Win7 x32

[clone2727]

Did you rerun configure and "make clean" after removing it from sdl-config?

[George Kormendi]

yes

make clean
configure --enable-all-engines
make
strip scummvm.exe

[clone2727]

I'm seeing *__p___argc() (what __argc is defined to) give me 0, even in a separate program. Using _argc and _argv works, however, but those are MinGW-specific variables. I'm using g++ 4.8.1.

Kirben, did something change on Win32 recently?

[kirben]

Not that I know of, I'm still using older build system (as listed in MinGW compile guide on wiki) with GCC 4.6.2 though.
No experience on the x64 side, I don't have a 64bit build system setup.

[clone2727]

Kirben: I built for 32-bit using normal MinGW32.

[kirben]

I'm still unable to reproduce the issue, with a basic compile of ScummVM Git, using a fresh manual install of MinGW with GCC 4.8.1 (from http://www.mingw.org/wiki/InstallationHOWTOforMinGW ).

I'm running Windows 7 SP1 x64.

[digitall]

I do not observe the issue with the latest mingw-w32-master-ca096e1d from buildbot when run under WinXP 32-bit.

[digitall]

Same result i.e. no bug replication with win32 reported version i.e. mingw-w32-master-51e5baa4

[digitall]

AHA! I have managed to replicate this with MinGW32 toolchain with GCC 4.8.1 which I installed a while back and have been using for some time when compiling the latest code version using: ./configure --disable-all-engines --enable-engine=sherlock --disable-nasm && make clean && make

This is odd as I swear this used to work with this toolchain and libraries as setup. I used mingw-get-inst-20111118.exe to do this around that date.

[digitall]

Hmm... I found that "-mwindows" was in my MinGW sdl-config. NB: If you want to know which sdl-config is being used from your path, the "which" command is your friend.

However, even after removing this and rebuilding with clean, I still get no output.

I have also checked the buildbot toolchains. The 32-bit MinGW toolchain had this modification already, but the x64 toolchain had -mwindows in it's sdl-config. I have now corrected this and we shall see if the user can test with the next nightly build if this fixes the observed issue...

[digitall]

Hmm, I have tried various releases back to an older version which the buildbot build did not exhibit the issue with and I still get the same problem with my local builds. This must be something about the MinGW setup recently, but this is odd as I haven't changed it recently... although I have updated SDL to 1.2.14 / 1.2.15, though have made the -mwindows patch to sdl-config now with no change :/

[clone2727]

Kirben: Does your 4.6.2 toolchain declare __p___argc as extern or _CRTIMP?

[kirben]

I'm using mingw runtime 3.20-2 and it is declared in stdlib.h as:

extern int*  __cdecl __MINGW_NOTHROW   __p___argc(void);
extern char*** __cdecl __MINGW_NOTHROW  __p___argv(void);
extern wchar_t***  __cdecl __MINGW_NOTHROW __p___wargv(void);

[kirben]

The problem is caused by using mingw runtime 4.x, and is a known issue. The MinGW developers don't seem to care at all, judging by response on their mailing list.

Just another case of why I don't like MinGW, and find it rarely worth updating. Maybe buildbot can be switched back to earlier mingw runtime (3.20-2) along with matching win32api version.

[clone2727]

Do you hsve a link to the mailing list post?

I think downgrading is a poor solution to the problem. Yes, it may be broken, but we can't just tell every user with runtime 4 to downgrade. Can we switch to using _argc/_argv for MinGW instead?

[kirben]

Message on the mailing list, MinGW developers don't care about the breakage/compatbility:
http://sourceforge.net/p/mingw/mailman/message/34379555/

MinGW generally has a lack of care about breakage, with ABI compability broken in GCC 4.7.0+ and mingw runtime 4.0+ too. Good reasons to never upgrade.

I will switch mingw to _argc/_argv since it is a small change, I don't like adding hacks for broken compilers though.

[digitall]

@kirben: While I tend to agree on the hacks, this seems more that they are indicating that the underscore prefixed versions of argc, argv are intended for internal usage only and shouldn't be used in user code anyway i.e. https://sourceforge.net/p/mingw/mailman/message/34381840/ To play "The Devil's Advocate" are these used because argc and argv are not directly accessible? i.e. this is a hack anyway?

[digitall]

But I tend to agree, they shouldn't break userspace and then just shrug... Sigh.

[digitall]

As for the original issue here i.e. the lack of x64 buildbot build command line output. I think that was my fault in omitting the sdl-config removal of -mwindows, and thus should have been fixed in the last nightly without modifying any of the buildbot toolchains. The testing I did with the x86 win32 buildbot build didn't show any issues, so if the x64 version is now good as well, the original issue has been solved and this ticket can be closed.

@kirben: As you have a Win7 SP1 x64 box, could you do a quick test with http://buildbot.scummvm.org/snapshots/master/mingw-w64-master-ca096e1d.zip and see if this is now fine? Thanks.

[clone2727]

Kirben: Thanks.

digitall: Actually, __argv and__argc are a documented part of the Windows API. See https://msdn.microsoft.com/en-us/library/dn727674.aspx. MinGW really is just broken here.

[digitall]

@clone2727: Ah OK.. SIGH. That is the MS Visual C Runtime API though? Do we need MSVCRT defined so we get the right definitions in the stdlib.h as I noticed that there are several different blocks with slightly varying definitions for __argc() etc. ?

[clone2727]

digitall: No, MinGW already defines that and that's the version of __argv and __argc being used. There's something wrong with the functions the macros call. I imagine if we pulled the functions out of the module manually it would work properly, but since _argc and _argv are available, I don't think there's a need to.