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]" <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>
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:
   <http://www.delorie.com/archives/browse.cgi?p=djgpp/2015/10/05/05:32:54>
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

- Raw text -