www.delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp-workers/2011/04/30/07:21:54

X-Authentication-Warning: delorie.com: mail set sender to djgpp-workers-bounces using -f
X-Recipient: djgpp-workers AT delorie DOT com
Message-ID: <4DBBEE1B.7090803@iki.fi>
Date: Sat, 30 Apr 2011 14:10:19 +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.15) Gecko/20110307 Fedora/3.1.9-0.39.b3pre.fc14 Lightning/1.0b2 Thunderbird/3.1.9
MIME-Version: 1.0
To: djgpp-workers AT delorie DOT com
Subject: DJGPP port of GCC: current situation and future
Reply-To: djgpp-workers AT delorie DOT com

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)

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.

Are there any other ideas?

Andris

PS. There is also libtool related problem that prevents native DJGPP
     build of last binutils versions. I have no time to try to fix it.
     I can however build DJGPP packages of binutils under Linux without
     problems.

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019