X-Authentication-Warning: delorie.com: mail set sender to djgpp-bounces using -f X-Recipient: djgpp AT delorie DOT com Message-ID: <562168C6.5050001@gmx.de> Date: Fri, 16 Oct 2015 23:14:46 +0200 From: "Juan Manuel Guerrero (juan DOT guerrero AT gmx DOT de) [via djgpp AT delorie DOT com]" User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; de; rv:1.9.2.13) Gecko/20101206 SUSE/3.1.7 Thunderbird/3.1.7 MIME-Version: 1.0 To: djgpp AT delorie DOT com Subject: Re: Random compile errors under WIndows (32 bit Windows Vista and Windows 10) References: <5611566C DOT 4020507 AT iki DOT fi> <561A4BCE DOT 7050606 AT iki DOT fi> <56213FE2 DOT 7090409 AT iki DOT fi> In-Reply-To: <56213FE2.7090409@iki.fi> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:QYz1KvZGoUZhEm2z79QaLG1+bWMYVurVnY8p6fowMgcEHKzsfNW GZpjs5/MSaQ2LR6M3QTEyHi0krDzeVNs9Hi4th1JLiZ09Di81Rdh2dVrpIKL+gvKmUfdCGN vnmMFYJS0Quy7WG8kbhBa1L4epalSCSy0WP/y4sdV7rfTOskLjaLiWYh6e6ymPzAM2ECHDO KHurNYMve01geq2wA8eVQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:zr7lS0Sb+2Q=:PJXzeZsz/vlJA54Z6YsfXz 5MYiA1Vu2kp/G4gFccWGovba/Igt4CSwb1rdi24Wmmqyn3OstnvZoQbB7gk2qiTHfrLon8LnC fBEAjVGjyfvwnoOwliR/T5xgZd/jzqde8a+RzRX/j7VB8FCURcVhPabT3rSWPOuFYWb+ULGKx 5UxbZkU3YSD8kJn0PiW5fNrScRTiEozSX5XJt1+Nsq5nrG0rxeMFW0jaHtK7q5LdiCk4bNuFD MKvkP2ueVvTtJquC9XFmKjClhFJmk4T/0fa+vGM6Y0Qw1Ya+Lmb+Lc6bp8ajuXSDjIdGZemKF 6XXbTzj02TsLV5D8jFg9yxlWXYkrw1kRJG6CPE4k91bE7kBATG/qX7BTOeQZonPT7DKbYqKCE INKaHbaLBtdRp83qO0kFZIaKuH2b8vy0grMBz/GRlh++v+xCo0iCRVLE9uS2uvILhA2plMHJk KeUYJTwZs18/Hxh7EtRG7qD2DvYq1C790q9qrlutRcLZKssc0vD0efoaXYqEtWK7NXQgxL0/T u7fq0ut5GLqI16aRdkcdeNRePVCf+Ov+8n6AUfUyNrxsAJOyp3QRmxpp+4S9QiryEnhDq5qOz Xd9EsE3QGsbEauyc6RHYmDyswctNCb+RlQUfdoyjy7aLTtbt3tjcHRmA273Vq8RetAOp6fuTn KMO87EXoYyc0cXptBvStPZIbcL9ig6NDd12IHCjPa5KpwHuCbZiXCpByZFnp2gl+Nxj7CcrkK E7QSFWYX25tR7KlKGDaikMZCXK1YymTqLVmStlD5ykkwCTXB7XLqPFqLT+5vh+0xDruyqV0dy TyEemwr Reply-To: djgpp AT delorie DOT com Am 16.10.2015 20:20, schrieb Andris Pavenis (andris DOT pavenis AT iki DOT fi) [via djgpp AT delorie DOT com]: > On 10/11/2015 02:45 PM, Andris Pavenis (andris DOT pavenis AT iki DOT fi) [via djgpp AT delorie DOT com] wrote: >> On 10/04/2015 07:40 PM, Andris Pavenis (andris DOT pavenis AT iki DOT fi) [via djgpp AT delorie DOT com] wrote: >>> I have earlier noticed random stray compile errors when building >>> DJGPP port of gcc under Windows Vista Business. Running make again >>> compiled some file without problems. Such errors where >>> extremely rare for DJGPP CVS from CVS (also 2.04 before bumping version >>> to 2.05). I usually did not get them at all for 2.04 or 2.05. The situation >>> was noticeably worse for 2.03p2. Building GCC was still possible but I had to >>> restart build often enough. >>> >>> I have 64-bit Windows 10 (earlier Windows 7) on desktop computer and dual boot >>> with Linux (currently Fedora 22 x86_64). So there no DJGPP testing possible in this >>> Windows installation for understandable reasons. >>> >>> Today downloaded 32 bit Windows 10 Enterprise 90 days trial from Microsoft and >>> installed it in VirtualBox VM under Linux. I needed slightly more steps to get DJGPP >>> working rather than on Windows Vista (for VIsta only registry hack was needed to >>> workaround 32MB DMPI memory limit) >>> >>> Trying to build gcc-5.2.0 on this Windows 10 installation (DJGPP v2.05 only) showed >>> that I'm getting stray compiler errors much more often (once per several minutes) >>> >>> These errors look like: >>> gpp -c -DIN_GCC_FRONTEND -DIN_GCC_FRONTEND -g -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-format -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common -DHAVE_CONFIG_H -I. -Ic-family -I/gcc-5.20/gcc -I/gcc-5.20/gcc/c-family -I/gcc-5.20/gcc/../include -I/gcc-5.20/gcc/../libcpp/include -I/gcc-5.20/gcc/../libdecnumber -I/gcc-5.20/gcc/../libdecnumber/dpd -I../libdecnumber -I/gcc-5.20/gcc/../libbacktrace -I/dev/env/DJDIR/include -o c-family/c-gimplify.o -MT c-family/c-gimplify.o -MMD -MP -MF c-family/.deps/c-gimplify.TPo /gcc-5.20/gcc/c-family/c-gimplify.c >>> In file included from /gcc-5.20/gcc/flags.h:24:0, >>> from /gcc-5.20/gcc/c-family/c-common.h:36, >>> from /gcc-5.20/gcc/c-family/c-gimplify.c:41: >>> ./options.h:10:0: error: unterminated #if >>> #if !defined(IN_LIBGCC2) && !defined(IN_TARGET_LIBS) && !defined(IN_RTS) >>> ^ >>> ./options.h:3:0: error: unterminated #ifndef >>> #ifndef OPTIONS_H >>> ^ >>> Makefile:1066: recipe for target 'c-family/c-gimplify.o' failed >>> make.exe[3]: *** [c-family/c-gimplify.o] Error 1 >>> make.exe[3]: Leaving directory 'c:/build.gcc/gcc' >>> Makefile:4376: recipe for target 'all-stage1-gcc' failed >>> make.exe[2]: *** [all-stage1-gcc] Error 2 >>> make.exe[2]: Leaving directory 'c:/build.gcc' >>> Makefile:17534: recipe for target 'stage1-bubble' failed >>> make.exe[1]: *** [stage1-bubble] Error 2 >>> make.exe[1]: Leaving directory 'c:/build.gcc' >>> Makefile:17838: recipe for target 'bootstrap' failed >>> make.exe: *** [bootstrap] Error 2 >>> >>> Same error do not repeat when I try to run 'sh ./djmake.sh bootstrap' again. >>> >>> Most likely explanation is that reading file (opened in binary mode) is unreliable >>> and one randomly gets corrupted data. Total data size is correct as libcpp compares >>> data size with one from response of stat() and reports an error in case of size discrepancy >>> (we needed to handle DOS end of file mark ^Z specially for that reason) >>> >>> It could be a bug in NTVDM. It could also be some problem on our side. >>> More testing is needed. Such test could repeatedly read some set of files into memory >>> and calculate MD5 sum or something similar to detect random corruptions. It would >>> be possible to investigate further and see what is getting corrupted >>> >>> >>> How to get DJGPP programs running on Windows 10 32 bit (please comment >>> if one has possibility to check on different edition) >> > Tried to investigate on same Win 10 Enterprise trial VM but no success up to this time: > > modified gcc/libcpp/files.c to calculate and dump to stderr MD5 sums of just read files. > Did not notice any problems reading files when repeated it may times (sort | uniq) even > when I had stray preprocessor output differences and errors (like missing #endif). So > reading files do not seem to be reason of problems > > Suspected use of -remap (DJGPP is perhaps only target for which it is used, had to fix a > related error rather long time ago). No influence > > Some more thoughts: > > 1) random DPMI memory corruption (for example from interrupts) in Windows (especially WIndows 10). > One would need a program that uses much memory and runs long enough and for which result can > be easily verified. https://gmplib.org/pi-with-gmp.html could be good candidate > 2) some problem on our side (for example use os uninitialized data) > > In case of (1) we may be out of luck. > > There was however similar problems with DJGPP v2.03p2 on Windows Vista, which I have not > any more noticed with 2.05. > > Andris > Please do not get me wrong, I really appreciate your efforts but all of your activity seems to imply that this will be again another week-end without the release of DJGPP 2.05. Are there any realistic chances that we will release DJGPP 2.05 before the end of the year? We are already working for at least 6 months on this. I really fear that we are again on the road to nowhere like with DJGPP 2.04. I gain the impression that we are confusing real impediments, that do not exist at all, with particular features that some developer would like to see implemented before this release gets released. No matter if we are talking about something like DXE support or if we are talking about windows 10 support. I would like to recall to all interested people that DJGPP is a 32-bit application that has been devolped to run on MS-DOS 3.1 or compatible operating systems that do either provide some kind of DPMI server or allow to install one. Absolute no one has ever promised that DJGPP would work on Vista, Windows 7, Windows 8, Windows 10 or what ever they may invent in the future. AFAIK Microsoft has clearly state that they are no longer interested in suporting MS-DOS applications on their OSs. And all DJGPP programs are MS-DOS applications that require a full functional DOS environment to work flawlessly, so IMO it becomes very unlikely that the goal of getting DJGPP working on modern Windows operating systems can ever be achived. I am not opposing on trying to get DJGPP working on Windows 10 or similar OS but in consideration of the fact of the small amount of DJGPP users and the even smaller amount of skilled DJGPP developers really familiar with DJGPP internals and Windows internals, this will take at least a couple of months more, probably it will take years. IMO, an attempt to get DJGPP working on Windows 10 or similar operating systems shall be postponed until 205 has been released. The over the years vanishing group of DJGPP users do not deserve to wait until the end of days for this release. I really think that we shall take seriously user questions like this one: http://www.delorie.com/archives/browse.cgi?p=djgpp/2015/09/29/12:45:12 and give a honest answer about when we definitively plan to release this thing. The last Microsoft operating system I have bought was Windows XP and I have no intentions to buy any other any more. This means that I do not really care if DJGPP works on Windows Vista and similar OS. If an user like me decides to try and to use DJGPP at all, then he is absolutely _aware_ that DJGPP is a DOS application and that it will certainly not run on any modern Microsoft operating system. Who says DJGPP is saying DOS and certainly not Windows specially not Windows 10. I think that I have proved, by all my checks lately done on MSDOS-6.22, Win98SE, Win2K and WinXP, that DJGPP as-it-is-now is absolute stable and is ready to be released right now. DJGPP does _NOT_ address any other operating system than the ones stipulated in the previous sentence and probably will never do, so we do not need to care about them. At least we do not need to care right now. We should concentrate the efforts on a quick release and not waist time defining goals that cannot be achived and then become impediments for the release. DJGPP is a DOS application and never will become Windows application. Basta. Please do not get me wrong. If the things I have expressed sounds rough it is only due to my limited english skills. There is no offending intention here. But from the experience of the last months envolved in this issue, I have seen confirmed again what I have learned in 25 years of working in the software industry: every release of a software needs at least 2 things: 1) one and only one release manager that is responsible for the release and with the absolute power to make decisions 2) a deadline that is binding for all involved personnel Without these 2 things we do not come to an end and we start to confuse issues of the category "nice-to-have" with real requirements. During the time being envolved in this issue sometimes I had the strong impression that we all were sailing on the titanic and the captain is missing. I really hope that we can quickly come to a release of DJGPP 2.05 or if not then I expect a clear explanation from you about what is missing and in which period of time you think that the missing and required feature can be provided by you. Without this information, we cannot decide if this feature is worth to be waiting for. Some weeks ago I send to DJ my latest version of the script together with a set of 00_index.txt files for all new /current directories that will be created by the release. If nothing has changed in the actual /beta tree we can proceed with the release of DJGPP in the near future. I really do not see any impediments at all. Meanwhile I have also inspected the patch submitted by Ozkan: to improve the DXE module support. It looks OK to me and I think it should go into the DJGPP 2.05 code. IMO this should be the _absolute last_ change allowed to be commited into the v2_05_1 branch and then we should release. > There was however similar problems with DJGPP v2.03p2 on Windows Vista, which I have not > any more noticed with 2.05. I have also not observed any nmalloc releated issues in the last months when I used it. I think that we can accept it as new memory system for DJGPP. Regards, Juan M. Guerrero