X-Authentication-Warning: delorie.com: mail set sender to djgpp-bounces using -f X-Recipient: djgpp AT delorie DOT com Message-ID: <55400870.3060408@gmx.de> Date: Wed, 29 Apr 2015 00:23:44 +0200 From: Juan Manuel Guerrero 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: GCC 5.1.0 problem with References: <201504280005 DOT t3S05t2U020439 AT delorie DOT com> <201504281718 DOT t3SHIpWZ009266 AT envy DOT delorie DOT com> In-Reply-To: <201504281718.t3SHIpWZ009266@envy.delorie.com> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:uVNfs8Rr1siYu7mh9gJl+KqDKTmFLk8I2WY+5BM2S1xBbEpAmOW NLhoUbXpYWt+11PufTnseIX102Msv26+SKiAzKfN66pN/qeJkgkMQKFJernNndj0QSB0UHr EHIM52CSFGDghxDiZHk+GueCGFA+a7hTJjLLbzVZ5jZ0cXCR5BqCe3tzwKF0dNgy6vknb79 RWuq5JrR24irHF0BLKJlQ== X-UI-Out-Filterresults: notjunk:1; Reply-To: djgpp AT delorie DOT com Am 28.04.2015 19:18, schrieb DJ Delorie: > Ah, I see. > > I see no reason to not spin a 2.05 release just to get this out, but > the only other issue we've had stopping this is the malloc one. IIRC > the last concern I had with changing malloc was breaking the ABI, but > if Juan and Andris can agree on what malloc "works" we'll just go with > that and have something that can replace both 2.03 and 2.04. I have been using the nmalloc patch posted by Andris in all my ports lately. I have never experienced any difficulties with the binaries using that malloc code. IIRC code compiled with it cannot be debuged, but Andris knows better. I have never tried to understand the code, I have simply used it to test it by using it. Fortunately I never had to debug memory issues so I never experienced any difficulties using nmalloc. Neitherless over the years I have experienced difficulties with binaries compiled using libc compiled from cvs repository when used on plain DOS (aka MSDOS 6.22 and FreeDOS). Unfortunately I have not documented them. These issues become visible when I try to configure and compile some contemporary GNU packages. This is not a LFN issue alone and cannot be solved by installing such a driver. Of course LFN support is always required for such projects. I think these are primarily issues related to the way the Windows file system works and supports NTVDM. To make the point clear, "djgpp 2.05" has always worked __very well__ for me when used on NTVDM (aka WinXP) and on Win98SE but it had some issues when used on plain DOS. I fear that the people who made a great job to get DJGPP working on Win2K and WinXP around the year 2000 and later no longer had MSDOS machines to recheck their code on plain DOS. For me that was never an issue, because I stoped using MSDOS long long time ago and as long as djgpp worked flawlessly on NTVDM I was happy. I have used djgpp to port GNU programs to DOS. Nowadays this is almost impossible using plain DOS. Alone the time to uncompress a file like binutils-2.25.tar.bz2 becomes prohibitive when a LFN driver is installed. But LFN support is absolutely necessary to configure and compile such a program. After having installed the source code, trying to configure and compile it on plain DOS becomes a nightmare. Not only because NTVDM is much faster than plain DOS but also because the used programs (compiled with djgpp) behave differently on NTVDM and plain DOS. IMHO a "djgpp 2.05" should be released because still a lot of people ask for it and they do not want to check it out from cvs repository and compile it by their own. But it should be clear that the DOS of today no longer is NTVDM but FreeDOS and it behaves very differently from NTVDM. So we should be prepared for some "bug" reports. Regards, Juan M. Guerrero