Cross compiling for the 1750A

[Kai Ruottu]

7.2.2012 11:03, Andrew Haley kirjoitti:

> On 02/06/2012 11:18 PM, ~Stack~ wrote:
>> I downloaded the as1750.tar.gz from kellogs website.
>> http://okellogg.de/x.html
>> Extracting it, and running make inside the folder just works.
>>
>> I created a build directory then ran:
>> /home/compile/gcc-3.1.1/configure --prefix=/home/compile/gcc-3.1.1-1750a
>> --target=1750a --with-as=/home/compile/as1750-1.2a/as1750
>> --disable-multilib --enable-languages=c --without-headers --disable-nls
>> --enable-obsolete
>>
>> No errors that I could see.
>>
>> Then I ran `make` and it compiled for a while but then it errored out
>> with the following:
>>
>> In file included from /home/compile/tmp/gcc-3.1.1/gcc/libgcc2.c:37:
>> /home/compile/tmp/gcc-3.1.1/gcc/tsystem.h:63:19: stdio.h: No such file
>> or directory
>> /home/compile/tmp/gcc-3.1.1/gcc/tsystem.h:63:19: sys/types.h: No such
>> file or directory
>> /home/compile/tmp/gcc-3.1.1/gcc/tsystem.h:63:19: errno.h: No such file
>> or directory
>> make[2]: ** [libgcc/./_muldi3.o] Error 1

I myself used the newlib headers here...

>> I did some searching online but most of the solutions I found shouldn't
>> apply to me (aka, I don't want c++ so I enabled only C and I have the
>> proper packages installed).
>>
>> Can someone point out where I went wrong?
>
> Nothing, you're doing fine.  The problem is that you don't have a C
> library.  You now have a C compiler.
>
> Did you look in the tarball for the C library?

The assembler tarball had only the assembler sources and some sources
for testing...

Generally the '1750a' port in the FSF sources is fuzzy, the 'as1750'
being both an assembler and a linker and producing of the 'libgcc.a'
told "not being possible", maybe meaning the same as "not required".

The alternative 'm1750-coff' target zipfile for Windoze then includes
a prebuilt C library with headers and library archives. Including a
prebuilt 'libgcc.a'. Trying to reproduce this on Linux with the just
built gcc-2.7.2 however crashes in the '__udivmodsi4.o' production :-(

When checking whether the Windoze-hosted gcc-2.7.2 really had
succeeded with this, the result was totally identical :

C:\w1750\src\gcc-2.7.2\temp>\w1750\bin\m1750-coff-gcc -mno-movsi -O2 
-I. -I.. -I../config -c -DL__udivmodsi4 ../libgcc2.c -o __udivmodsi4.o
../libgcc2.c: In function `__udivmodsi4':
../libgcc2.c:1695: Unable to find a register to spill.
(insn:HI 21 18 24 (set (reg/v:HI 24)
         (mem/s:HI (plus:QI (reg:QI 14 r14)
                 (const_int 11)))) 87 {movhi+1} (nil)
     (nil))
m1750-coff-gcc: Internal compiler error: program cc1 got fatal signal 17

Ok, the signal # was different... Somehow also this function was made
because the 'cpp1750.zip' included it in its 'libgcc.a'. Editing its
production away from the Makefile let a "stripped" libgcc.a being done
and the gcc-2.7.2 build to go into a happy end...

Implementing an equivalent to the 'cpp1750.zip' toolchain for a Linux
host "as it is" should so be fully possible :

[root@localhost local]# ls -l bin/m1750-coff-*
-rwxr-xr-x 2 root root 133952  1. helmi  09:49 bin/m1750-coff-ar
-rwxr-xr-x 2 root root 235744  1. helmi  09:49 bin/m1750-coff-as
-rwxr-xr-x 2 root root  16682  3. helmi  16:17 bin/m1750-coff-c++
-rwxr-xr-x 1 root root  22632  1. helmi  09:49 bin/m1750-coff-c++filt
-rwxr-xr-x 2 root root  16682  3. helmi  16:17 bin/m1750-coff-g++
-rwxr-xr-x 1 root root  40164  1. helmi  09:49 bin/m1750-coff-gasp
-rwxr-xr-x 1 root root  65028  3. helmi  16:18 bin/m1750-coff-gcc
-rwxr-xr-x 2 root root 224564  1. helmi  09:49 bin/m1750-coff-ld
-rwxr-xr-x 2 root root 142632  1. helmi  09:49 bin/m1750-coff-nm
-rwxr-xr-x 1 root root 241488  1. helmi  09:49 bin/m1750-coff-objcopy
-rwxr-xr-x 1 root root 247432  1. helmi  09:49 bin/m1750-coff-objdump
-rwxr-xr-x 2 root root 133952  1. helmi  09:49 bin/m1750-coff-ranlib
-rwxr-xr-x 1 root root 121704  1. helmi  09:49 bin/m1750-coff-size
-rwxr-xr-x 1 root root 121680  1. helmi  09:49 bin/m1750-coff-strings
-rwxr-xr-x 2 root root 241488  1. helmi  09:49 bin/m1750-coff-strip
[root@localhost local]# ls -l m1750-coff/bin
yhteensä 1212
-rwxr-xr-x 2 root root 133952  1. helmi  09:49 ar
-rwxr-xr-x 2 root root 235744  1. helmi  09:49 as
-rwxr-xr-x 1 root root  65028  3. helmi  16:18 gcc
-rwxr-xr-x 2 root root 224564  1. helmi  09:49 ld
-rwxr-xr-x 2 root root 142632  1. helmi  09:49 nm
-rwxr-xr-x 2 root root 133952  1. helmi  09:49 ranlib
-rwxr-xr-x 2 root root 241488  1. helmi  09:49 strip
[root@localhost local]# ls -l m1750-coff/lib
yhteensä 652
-rw-r--r-- 1 root root   1632 19. elo     1997 crt0.o
-rw-r--r-- 1 root root  14677 15. touko   1997 crt0.s
drwxr-xr-x 2 root root   4096  1. helmi  09:47 ldscripts
-rw-r--r-- 1 root root 128068 19. elo     1997 libc.a
-rw-r--r-- 1 root root 128068 19. elo     1997 libg.a
-rw-r--r-- 1 root root  19570 19. elo     1997 libgcc.a
-rw-r--r-- 1 root root  29078 19. elo     1997 libm.a
-rw-r--r-- 1 root root 271058 19. elo     1997 libpthread.a
drwxr-xr-x 2 root root   4096 27. heinä   2004 mmmu

and so on...

The '1750a' port doesn't include any 'mmmu' multilib variation etc. But
seems to be "supported" up to gcc-3.1*, also building from the gcc-3.2.3
sources will succeed when using '--enable-obsolete' in configure...