X-Authentication-Warning: delorie.com: mail set sender to djgpp-bounces using -f X-Recipient: djgpp AT delorie DOT com X-Original-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=8ska2mg5/lsCA/OSj1c1rd8muTIiP5LDBCocAJQu9FU=; b=w3NsUz2T+uJ/Tryovut5OgoJWTxbTQxH3eiTtr4qTRXgv8XhAWChpdoT6oEiPegS/j LZkmJXZRDOafgrgcts4Bee/+W2t0aOZD5MV+2/ljHgTyv2c30YTiNctMwxnt+3Xssdno NsfT4B5JsQW7wudcX/gj2IppKnx6qnPfU4IO+Se7YhUnR5IrZ6r58X3be4ZjrYAeXj4H MzCxoMMNxgknao50AKkVWa/+ed0XqD7G+JDxXlSR6y00cvpL68rKEwbE7uSy6X1mwUEK W4mYMYhIJIonwWpJ3/Wl5SVOWxKD9Hyv/W6OI77Dl9nbQY+LfDyjOWG+N6FcdZ5T4CRR RRcQ== MIME-Version: 1.0 X-Received: by 10.60.133.102 with SMTP id pb6mr4446150oeb.50.1432850436117; Thu, 28 May 2015 15:00:36 -0700 (PDT) In-Reply-To: References: <201505042003 DOT t44K3odg011007 AT delorie DOT com> Date: Thu, 28 May 2015 15:00:35 -0700 Message-ID: Subject: Re: ANNOUNCE: DJGPP 2.05 beta 1 From: "Louis Santillan (lpsantil AT gmail DOT com)" To: "djgpp AT delorie DOT com" Content-Type: text/plain; charset=UTF-8 Reply-To: djgpp AT delorie DOT com Errors-To: nobody AT delorie DOT com X-Mailing-List: djgpp AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk I have a minor 2.04 libc header bug that probably also exists 2.05. I just recently ported lz4 [0] to djgpp via Andrew Wu's build-djgpp 2.04 cross compilers [1]. It's currently on the dev branch of lz4 and due to be included on the next release of master. In porting, I noticed that using `cc -std=c99` confuses the djgpp headers such that the main bodies of the headers get nullified for io.h, fcntl.h, and unistd.h. This is because `-std=c99` implies `__STRICT_ANSI__` which is guarded against in those headers and probably others. The simple work around is to instead use `-std=gnu99` which does not imply `__STRICT_ANSI__` and brings in the needed function prototypes (isatty(), setmode(), a couple others). [0] https://github.com/lpsantil/lz4 [1] https://github.com/andrewwutw/build-djgpp/releases On Thu, May 28, 2015 at 12:11 PM, Ozkan Sezer (sezeroz AT gmail DOT com) wrote: > On 5/28/15, Ozkan Sezer wrote: >> On 5/4/15, Andris Pavenis (andris DOT pavenis AT iki DOT fi) >> wrote: >>> This is announcement of DJGPP 2.05 beta 1 >>> >>> It has numerous changes since previous DJGPP 2.04 beta 1 release in 2003. >>> (http://www.delorie.com/djgpp/mail-archives/browse.cgi?p=djgpp-announce/2003/12/06/22:18:05) >>> Unfortunately DJGPP v2.04 was never released and old beta version slowly >>> became almost unusable together with other newer DJGPP packages. >>> >>> More information about changes in DJGPP 2.05 beta 1 is available at >>> >>> http://www.delorie.com/djgpp/doc/kb/ >>> >>> both in sections about changes in 2.04 and 2.05. The same information is >>> also >>> available in file info/kb.inf in djdev205.zip >>> >>> It needs a lot of testing. Please test it if you have time and/or are >>> interested in any of the above features. Any level of testing would be >>> appreciated. >> >> Some dxe3gen and dxe3res issues: They are not flexible with relation to >> development environment: >> >> 1. As it seems, they were designed to be run under dos-djgpp not with a >> cross-toolchain, i.e. dxe3gen expects 'gcc', 'as', 'ar' and 'ld' to be >> djgpp-targeting tools. Well, ld _can_ be changed to be a cross-ld, but >> only at compile time. User must have the ability to specify his choice >> of tools. >> - We may make dxe3gen to check environment variables such as DXE_CC, >> DXE_AS, DXE_AR and DXE_LD whose values will be the names of the tools >> of choice. (Maybe even a common DXE_CROSS_PREFIX to cover all those >> at once??) >> - Command line switches instead? (Environment vars seem better to me.) >> >> 2. Strict requirement for DXE_LD_LIBRARY_PATH environment is rude for >> cross-compilers. It should be optional ifndef DJGPP > > I was miserably wrong about the DXE_LD_LIBRARY_PATH. Noticed that I > was testing with some stale environment vars set > >> >> 3. dxe3gen sends -T dxe.ld to ld, but the user can't specify a choice >> of linker script. (One consequence is when compiling djgpp itself with >> old toolchains, the toolchain-provided dxe.ld is used instead of the >> one in the source tree.) Maybe add a '-T' switch to dxe3gen itself?? > > .. was wrong about the wrong script part too like above. (Sorry.) > > >> >> 3. Both dxe3gen and dxe3res expect little endian host. On the other >> hand, their father tool dxegen swaps bytes as required. Needs fixing. >> >> Thoughts? >>