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...