Opened 8 years ago

Closed 8 years ago

Last modified 5 years ago

#6907 closed defect (fixed)

SCUMMVM: scummvm -v returns nothing

Reported by: SF/superzanac Owned by: Kirben
Priority: normal Component: Port: Win32
Version: Keywords:
Cc: Game:


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

Ticket imported from: bugs/6907.

Change History (31)

comment:1 by goodoldgeorge, 8 years ago

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

comment:2 by SF/mthreepwood, 8 years ago

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

comment:3 by goodoldgeorge, 8 years ago

"-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

comment:4 by SF/mthreepwood, 8 years ago

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

comment:5 by goodoldgeorge, 8 years ago


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

comment:6 by SF/mthreepwood, 8 years ago

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?

comment:7 by Kirben, 8 years ago

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.

comment:8 by SF/mthreepwood, 8 years ago

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

comment:9 by Kirben, 8 years ago

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 ).

I'm running Windows 7 SP1 x64.

comment:10 by digitall, 8 years ago

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

comment:11 by digitall, 8 years ago

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

comment:12 by digitall, 8 years ago

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.

comment:13 by digitall, 8 years ago

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...

comment:14 by digitall, 8 years ago

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 :/

comment:15 by SF/mthreepwood, 8 years ago

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

comment:16 by Kirben, 8 years ago

I'm using mingw runtime 3.20-2 and it is declared in stdlib.h as: ~~~~ extern int* __cdecl __MINGW_NOTHROW __pargc(void); extern char*** _cdecl MINGW_NOTHROW __pargv(void); extern wchart*** cdecl __MINGW_NOTHROW __p___wargv(void); ~~~~

comment:17 by Kirben, 8 years ago

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.

comment:18 by SF/mthreepwood, 8 years ago

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?

comment:19 by Kirben, 8 years ago

Message on the mailing list, MinGW developers don't care about the breakage/compatbility:

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.

comment:20 by digitall, 8 years ago

@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. To play "The Devil's Advocate" are these used because argc and argv are not directly accessible? i.e. this is a hack anyway?

comment:21 by digitall, 8 years ago

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

comment:22 by digitall, 8 years ago

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 and see if this is now fine? Thanks.

comment:23 by SF/mthreepwood, 8 years ago

Kirben: Thanks.

digitall: Actually, __argv and__argc are a documented part of the Windows API. See MinGW really is just broken here.

comment:24 by digitall, 8 years ago

@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. ?

comment:25 by SF/mthreepwood, 8 years ago

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.

comment:26 by Kirben, 8 years ago

I added changes to ScummVM Git, hopefully that will fix 32bit and 64bit builds. still fails to show version, when I try on windows 7 SP1 x64

comment:27 by goodoldgeorge, 8 years ago

Working, thanks :-) windows 7 32bit build scummvm -v ScummVM 1.8.0git (Oct 8 2015 06:29:22) Features compiled in: TAINTED Vorbis FLAC MP3 RGB zLib MPEG2 FluidSynth Theora AAC FreeType2 JPEG PNG

comment:28 by SF/superzanac, 8 years ago

Looks like fixed:

D:\My games\SCUMM\mingw-w64-master-3c6cf2b9>scummvm -v ScummVM 1.8.0git4746-g3c6cf2b (Oct 8 2015 04:10:14) Features compiled in: TAINTED Vorbis FLAC MP3 RGB zLib Theora AAC FreeType2 JPEG PNG

comment:29 by digitall, 8 years ago

Closing as fixed...

comment:30 by digitall, 8 years ago

Owner: set to Kirben
Resolution: fixed
Status: newclosed

comment:31 by digitall, 5 years ago

Component: Port: Win32
Note: See TracTickets for help on using tickets.