Re: Cross compiling for the 1750A

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [Linux C Programming]     [Linux Kernel]     [eCos]     [Fedora Development]     [Fedora Announce]     [Autoconf]     [The DWARVES Debugging Tools]     [Yosemite Campsites]     [Yosemite News]     [Linux GCC]

  Powered by Linux