X-Authentication-Warning:	delorie.com: mail set sender to djgpp-workers-bounces using -f
X-Recipient:	djgpp-workers AT delorie DOT com
Message-ID:	<4DC64CBC.4090301@iki.fi>
Date:	Sun, 08 May 2011 10:56:44 +0300
From:	Andris Pavenis <andris DOT pavenis AT iki DOT fi>
User-Agent:	Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110428 Fedora/3.1.10-1.fc14 Lightning/1.0b2 Thunderbird/3.1.10
MIME-Version:	1.0
To:	djgpp-workers AT delorie DOT com
Subject:	Re: DJGPP port of GCC: current situation and future
References:	<4DBBEE1B DOT 7090803 AT iki DOT fi>
In-Reply-To:	<4DBBEE1B.7090803@iki.fi>
Reply-To:	djgpp-workers AT delorie DOT com

On 04/30/2011 02:10 PM, Andris Pavenis wrote:
> Current situation:
> - no serious problems to build GCC (GCC-4.6.0 including) as
> Linux to DJGPP cross-compiler
> - Some tricks required for native DJGPP build of GCC
> - each recursive make and bash level eats <640K DOS memory.
> If one runs out of it, then build fails. The amount of
> DOS memory available under Windows XP and Windows Vista
> is barely enough for building version 4.5.X. I do not
> know whether it is still so with GCC-4.6.0 or DOS memory
> amount will be insufficient
> - the limitation of filename length has forced to put
> build directory directly under disk root directory
> already for GCC-4.5.X. As result native build may fail
> even source archive is unpacked in root directory
> - beginning with GCC-4.6.0 one runs into COFF format
> restrictions when compiling generated insn-attrtab.c.
>
> /usr/lib64/gcc/i586-pc-msdosdjgpp/4.6.0/../../../../i586-pc-msdosdjgpp/bin/as: insn-attrtab.o:
> .text: reloc overflow: 0x16ce2 > 0xffff
>
> Even without debug information GAS fails for most used
> GCC optimization levels (for example -O2). Only optimization
> level what is still usable is -Os. I guess that even that
> will fail for the following GCC versions
> The first 2 of these problems affects only native DJGPP build
> of GCC, but the third also cross-native builds (for example
> building GCC as native compiler for DJGPP using cross-compiler
> and other cross-tools under Linux)

Specifying STAGE1_CFLAGS="-Os" STAGE_CFLAGS="-Os" seems to be sufficient for now
do perform native build. I have however no idea for how many next versions it will
work. However building Ada tools (top level makefile target all-gnattools) fails
to build gnatchop at least for DJGPP v2.04 development version. I have no experience
with Ada and its tools myself, so I'll have perhaps no other way rather than
leaving native Ada compiler for DJGPP out for now.

>
> As result one can guess that the time when we can have GCC latest
> versions as native DJGPP compiler has come to end. The question is
> what we are going to do. It may be possible to still do native
> build of GCC-4.6.0 for DJGPP (or maybe not), but it is clear that
> in future such attempts earlier or later will fail.
>
> The remaining way is to use cross-compiler for DJGPP target.
> Some possibilities:
> - Linux to DJGPP cross-compiler. I have built gcc-4.6.0 cross-compiler
> RPM packages under Fedora 14 x86_64 and now Fedora 15 beta x86_64
> (the same gcc-4.6.0 as system compiler so no need to begin
> with native bootstrap of GCC on build system). Currently gcc-4.6.0
> cross-compiler RPM packages is being built in CentOS-5.6 chroot (i386)
> for distribution.
> - Using one of windows ports (Cygwin or Mingw32) as the host of
> DJGPP cross-compiler. I may try to to Canadian-cross build under
> Fedora 14 or Fedora-15 beta, as Mingw32 cross-development tools are
> already available in last Fedora distribution versions. We do not
> however have established way of distributing Mingw32 hosted
> cross-development packages for DJGPP target yet. Building using
> Mingw32 under windows is also an option.

Additionally cross-native build under Linux
- does not work without manually modifying gcc/Makefile (tries to do fixincludes
   and gets lost trying to find DJGPP include files)
- building Ada compiler, libraries and tools using cross-compiler does not
   work (all of them should work to succeed). I can only guess that no one
   else have even seriously tried to get it working (absence of something like
   GNATMAKE_FOR_TARGET etc in Makfiles).

Additionally absence of stdint.h in DJGPP v203r2 is causing problems when
building libstdc++-v3. I patched gcc/ginclude/stdint-wrapper.h to use
stdint-gcc.h (which commes with gcc) instead for DJGPP v2.03 only.

Andris

- Raw text -