#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: |
Description
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 , 9 years ago
comment:3 by , 9 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 , 9 years ago
Did you rerun configure and "make clean" after removing it from sdl-config?
comment:6 by , 9 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 , 9 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:9 by , 9 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 http://www.mingw.org/wiki/InstallationHOWTOforMinGW ).
I'm running Windows 7 SP1 x64.
comment:10 by , 9 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 , 9 years ago
Same result i.e. no bug replication with win32 reported version i.e. mingw-w32-master-51e5baa4
comment:12 by , 9 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 , 9 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 , 9 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 , 9 years ago
Kirben: Does your 4.6.2 toolchain declare __p___argc as extern or _CRTIMP?
comment:16 by , 9 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 , 9 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 , 9 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 , 9 years ago
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.
comment:20 by , 9 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. 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?
comment:21 by , 9 years ago
But I tend to agree, they shouldn't break userspace and then just shrug... Sigh.
comment:22 by , 9 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 http://buildbot.scummvm.org/snapshots/master/mingw-w64-master-ca096e1d.zip and see if this is now fine? Thanks.
comment:23 by , 9 years ago
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.
comment:24 by , 9 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 , 9 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 , 9 years ago
I added changes to ScummVM Git, hopefully that will fix 32bit and 64bit builds.
mingw-w64-master-ca096e1d.zip still fails to show version, when I try on windows 7 SP1 x64
comment:27 by , 9 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 , 9 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:30 by , 9 years ago
| Owner: | set to |
|---|---|
| Resolution: | → fixed |
| Status: | new → closed |
comment:31 by , 5 years ago
| Component: | → Port: Win32 |
|---|
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