Mail Archives: djgpp-workers/2011/04/30/07:57:34
> Date: Sat, 30 Apr 2011 14:10:19 +0300
> From: Andris Pavenis <andris DOT pavenis AT iki DOT fi>
>
> - 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
Anyway, are there any tricks to decrease the size/number of the
relocations? E.g., is it possible to divide insn-attrtab.c into a
several files?
> Even without debug information GAS fails for most used
> GCC optimization levels (for example -O2).
Why does this happen? What limitation do we hit here? Or is this the
reason for the "reloc overflow" failure?
> 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.
I guess the Linux to DJGPP cross-compiler is the easiest and most
convenient way, right?
It would be good to have a DJGPP native compiler for at least some of
the 4.6.x series, because support for debugging there is said to be
much better.
Anyway, let me take this opportunity to thank you for maintaining the
ports of GCC and Binutils over the years.
- Raw text -