i386-go32 problem in gas-971208

i386-go32 problem in gas-971208

[Joel Sherrill]

I recently switched from binutils 2.8.1 to gas-971208 and ran into the
following problem building for i386-go32-rtems:

Testing libgcc1.  Ignore linker warning messages.
/usr1/rtems/work/tools/build-i386-go32-tools/gcc/xgcc
-B/usr1/rtems/work/tools/build-i386-go32-tools/gcc/ -DCROSS_COMPILE
-DIN_GCC    -O2 -g -I./include  libgcc1-test.o -o libgcc1-test \
  -nostartfiles -nostdlib
`/usr1/rtems/work/tools/build-i386-go32-tools/gcc/xgcc
 -B/usr1/rtems/work/tools/build-i386-go32-tools/gcc/
--print-libgcc-file-name`
/usr1/rtems/work/tools/build-i386-go32-tools/gcc/collect-ld: target
coff-go32-exe not found
collect2: ld returned 1 exit status

The same build procedure worked fine for 2.8.1.  Any ideas what broke?

Thanks.

--joel

Re: i386-go32 problem in gas-971208

[Ian Lance Taylor]

   Date: Thu, 11 Dec 1997 09:01:48 -0600 (CST)
   From: Joel Sherrill <joel@OARcorp.com>

   I recently switched from binutils 2.8.1 to gas-971208 and ran into the
   following problem building for i386-go32-rtems:

   Testing libgcc1.  Ignore linker warning messages.
   /usr1/rtems/work/tools/build-i386-go32-tools/gcc/xgcc
   -B/usr1/rtems/work/tools/build-i386-go32-tools/gcc/ -DCROSS_COMPILE
   -DIN_GCC    -O2 -g -I./include  libgcc1-test.o -o libgcc1-test \
     -nostartfiles -nostdlib
   `/usr1/rtems/work/tools/build-i386-go32-tools/gcc/xgcc
    -B/usr1/rtems/work/tools/build-i386-go32-tools/gcc/
   --print-libgcc-file-name`
   /usr1/rtems/work/tools/build-i386-go32-tools/gcc/collect-ld: target
   coff-go32-exe not found
   collect2: ld returned 1 exit status

   The same build procedure worked fine for 2.8.1.  Any ideas what broke?

It means that the linker tried to create a BFD of type coff-go32-exe,
but that BFD type was not defined.

The go32 code was changed around by Robert Hoehne
<robert.hoehne@Mathematik.TU-Chemnitz.DE>.  Part of that change was to
change the target name used by go32 to i386-pc-msdosdjgpp.  This
doesn't work well with the RTEMS configuration triplet of
i386-go32-rtems.

Actually, a triplet of i386-go32-rtems doesn't make much sense to me,
now that I think about it.  I'm not sure what it is supposed to mean.
i386-*-rtems should have a single object file format.  If you want to
support a different object file format, you should have a target like
i386-*-rtemself or whatever.

The snapshot isn't working because ld and bfd treat the
i386-go32-rtems target differently.

Ian

Re: i386-go32 problem in gas-971208

[Joel Sherrill]

On Thu, 11 Dec 1997, Ian Lance Taylor wrote:

> 
> The go32 code was changed around by Robert Hoehne
> <robert.hoehne@Mathematik.TU-Chemnitz.DE>.  Part of that change was to
> change the target name used by go32 to i386-pc-msdosdjgpp.  This
> doesn't work well with the RTEMS configuration triplet of
> i386-go32-rtems.

Got it.  It is compiling OK now.

> Actually, a triplet of i386-go32-rtems doesn't make much sense to me,
> now that I think about it.  I'm not sure what it is supposed to mean.
> i386-*-rtems should have a single object file format.  If you want to
> support a different object file format, you should have a target like
> i386-*-rtemself or whatever.

RTEMS has a bunch of what I call "normal" configurations and a handful of
oddities.  It is the oddities I have trouble naming.

i386-go32-rtems is based on  djgpp v1 (yes old) and uses the go32 dos
extender to go into protected mode and kick off the rtems application.  It
requires slightly different newlib configuration and crt0.o as well as
some support libraries from the djgpp distribution.  This toolset
configuration is subtly different from the vanilla embedded i386-rtems
configuration.  I really do not know what this one should be named.

This ignores the harder rtems configurations like the ports to unix
(solaris, linux, and hpux) where you can test rtems applications without
a cpu simulator or real hw. :)

--joel