From: Keith M. <kei...@us...> - 2013-12-05 22:24:15
|
On 05/12/13 06:18, Kevin Scott wrote: > I am using MinGW on two computers; the main (newer) one is XP, > and the other (older) one is W98. With the version of MinGW > that I got in July 2012, it ran (and still fully runs), without > any significant problems, on both systems. It may be that, to continue supporting the W98 legacy system, you should stick with legacy GCC, binutils, and MinGW runtimes. > But with the more recent version that I got in Sept. 2013, which > includes the latest gcc (4.8.1-4), I'm having some trouble, both with > using it directly to build my software on the W98 system, as well as > to build my software on the XP system and then copy the resulting > .EXEs to run on the W98 system. > > I think this is a combination of two problems. One is 32-bit vs. > 64-bit time, Indeed. The 64-bit time functions have evolved significantly since W98, and are likely to present an obstacle to legacy support. > and the other is that the newer gcc may be emitting code that doesn't > run on the older processor (which is a Pentium with MMX). I don't know how likely this is to be the issue; perhaps someone, with more familiarity with GCC internals than I, could comment. > First, the problem with 64-bit time. I copied the complete MinGW > directory tree (the newer one from Sept. 2013, with gcc 4.8.1-4) > onto the W98 system, and tried doing a compile. It ran MAKE.EXE > and CC1.EXE just fine, but when it got to AS.EXE, it put up a > dialog box: > "Error Starting Program." > "The AS.EXE file is linked to > missing export MSVCRT.DLL:_ctime64" This suggests that the version of binutils you are using has a 64-bit time dependency. You could try substituting just a legacy version of binutils only. > Since (at least for now) the assembler won't run on the W98 > system, I tried building on the XP system, and then copying the > resulting .EXE to the W98 system. Doing this on an .EXE built > under XP with the older MinGW (July 2012 with gcc 4.7.2), it > worked fine on the W98 system. But doing this on an .EXE built > under XP with the relatively-current MinGW (with gcc 4.8.1-4), > I run into another 64-bit time problem, getting a dialog box: > "Error Starting Program." > "The ECHOLN_NEW_XP.EXE file is linked > to missing export MSVCRT.DLL:_ftime64" > > I then looked into the use of _USE_32BIT_TIME_T. Personally, I consider this to be a hideous and unreliable kludge; I prefer to probe the runtime, (using GetProcAddress), for the 64-bit function, and invoke it explicitly if present, otherwise invoke the generic (old) function with 32-bit semantics. > As I understand it, you're supposed to #define this before #including > any header having to do with time. You need to define it before you include *any* header, period. How else can you be sure that some indirect reference will not have made it already too late? > So I did that, and on XP, rebuilt my program. When I copy this > version of it to W98 and run it, I get the following dialog box: > "This program has performed an illegal > operation and will be shut down. > If the problem persists, contact the program vendor." > Under "details", it shows that it executed an invalid instruction. > Bytes at CS:EIP (0167:0040BB70): > 0F 44 C2 8D 53 02 0F 44 DA 00 C0 83 DB 03 29 FB This conveys no useful information. > (registers & stack dump omitted for brevity). This may have been more useful, but really, to be of any value, you need to trace the program execution, about the point of failure, in a debugger, such as GDB. > The same (small and simple) program runs without any problem on > the XP system, from both the 32-bit time and default-sized time > builds. > > For the 64-bit time issue, what are the plans of the MinGW > community as to whether the distributed .EXE files should have > dependencies on MSVCRT 64-bit time functions, or when the > transition will occur toward them having such dependencies? Formally, we no longer support W98. Microsoft declared it dead long ago, and as new technologies have emerged, it has become increasingly difficult for us to continue legacy support. I no longer have access to anything older than XP. Unless we are joined by an enthusiast, who is willing to follow up such legacy issues, we simply do not have the resources to pursue them. > For the invalid-instruction issue, any ideas? No. I could speculate, but to do so would surely be futile. > I verified the checksum of the .EXE file on both systems, and there > was no corruption of it in the copy process. I did a quick Google > search on "gcc pentium illegal operation" and got nothing. You need to trace the application in GDB, to identify the source, and cause, of the failure. -- Regards, Keith. |