Re: building a new (nios2) toolchain starting with uclibc

[Mike Frysinger]

On Thursday 18 October 2007, Robert P. J. Day wrote:
>   as an experiment, i want to create an updated version of a Nios II
> toolchain, and i thought i'd start with testing whether i could just
> compile the latest version of uclibc with the older toolchain, and
> take it from there.
>
>   first, i already have a nios2 cross-compiler toolchain from here:
>
> http://nioswiki.jot.com/WikiHome/OperatingSystems/%C2%B5Clinux/BinaryToolch
>ain
>
> that toolchain is based on gcc-3.4.6 so, as a first exercise, i
> thought it would be educational to see if i could cross-compile the
> latest svn checkout of uclibc with it.

there should be no problems with gcc-3.4.6 and any architecture on the uClibc 
side  of things.  there is someone on bugs.uclibc.org who has spent a lot of 
time getting nios2 things working in uClibc again.

> -rw-r--r-- 1 rpjday rpjday   5544 2006-05-07 09:57 elf2flt.ld

ah elf2flt, how i stab thee ... this will require custom modifications to your 
binutils install step

>   is this a sane way to start the process -- just to see where the
> older toolchain has problems building the current version of uclibc,
> and seeing if there's an obvious fix?  thanks.

i'm pretty sure svn trunk of uClibc actually has a decent nios2 status.  it'd 
prob be faster to go the other way -- enable everything you expect and only 
turn off upon failure.
-mike


signature.asc
Description: This is a digitally signed message part.
___
uClibc mailing list
uClibc@uclibc.org
http://busybox.net/cgi-bin/mailman/listinfo/uclibc

building a new (nios2) toolchain starting with uclibc

[Robert P. J. Day]

  as an experiment, i want to create an updated version of a Nios II
toolchain, and i thought i'd start with testing whether i could just
compile the latest version of uclibc with the older toolchain, and
take it from there.

  first, i already have a nios2 cross-compiler toolchain from here:

http://nioswiki.jot.com/WikiHome/OperatingSystems/%C2%B5Clinux/BinaryToolchain

that toolchain is based on gcc-3.4.6 so, as a first exercise, i
thought it would be educational to see if i could cross-compile the
latest svn checkout of uclibc with it.

  the toolchain has the following contents in "lib":

-rw-r--r-- 1 rpjday rpjday   1508 2006-05-07 09:54 crt1.o
-rw-r--r-- 1 rpjday rpjday   1069 2006-05-07 09:54 crti.o
-rw-r--r-- 1 rpjday rpjday   1075 2006-05-07 09:54 crtn.o
-rw-r--r-- 1 rpjday rpjday   5544 2006-05-07 09:57 elf2flt.ld
drwxr-xr-x 3 rpjday rpjday   4096 2006-05-07 09:53 gcc
drwxr-xr-x 2 rpjday rpjday   4096 2006-05-07 09:50 ldscripts
-rw-r--r-- 1 rpjday rpjday 994734 2006-05-07 09:54 libc.a
-rw-r--r-- 1 rpjday rpjday  13038 2006-05-07 09:54 libcrypt.a
-rw-r--r-- 1 rpjday rpjday 796072 2006-05-07 09:57 libiberty.a
-rw-r--r-- 1 rpjday rpjday 204618 2006-05-07 09:54 libm.a
-rw-r--r-- 1 rpjday rpjday772 2006-05-07 09:54 libnsl.a
-rw-r--r-- 1 rpjday rpjday 100344 2006-05-07 09:54 libpthread.a
-rw-r--r-- 1 rpjday rpjday778 2006-05-07 09:54 libresolv.a
-rw-r--r-- 1 rpjday rpjday   9964 2006-05-07 09:54 librt.a
-rw-r--r-- 1 rpjday rpjday  35600 2006-05-07 09:54 libthread_db.a
-rw-r--r-- 1 rpjday rpjday   5592 2006-05-07 09:54 libutil.a

  now, if i configure uclibc fairly minimally (static flat target file
format, no POSIX threading, no math lib, etc.), i can in fact get a
successful build, with the following contents in the new "lib"
directory:

-rw-rw-r-- 1 rpjday rpjday   1564 2007-10-18 08:29 crt1.o
-rw-rw-r-- 1 rpjday rpjday956 2007-10-18 08:29 crti.o
-rw-rw-r-- 1 rpjday rpjday920 2007-10-18 08:29 crtn.o
-rw-rw-r-- 1 rpjday rpjday 746674 2007-10-18 08:29 libc.a
-rw-rw-r-- 1 rpjday rpjday  12602 2007-10-18 08:27 libcrypt.a
-rw-rw-r-- 1 rpjday rpjday  79142 2007-10-18 08:28 libm.a
-rw-rw-r-- 1 rpjday rpjday772 2007-10-18 08:28 libnsl.a
-rw-rw-r-- 1 rpjday rpjday778 2007-10-18 08:28 libresolv.a
-rw-rw-r-- 1 rpjday rpjday   9744 2007-10-18 08:28 librt.a
-rw-rw-r-- 1 rpjday rpjday   5688 2007-10-18 08:28 libutil.a

  so it's a subset of the above, but it at least built.  at this
point, my plan would be to start adding features to the configuration,
seeing which ones break and seeing if i could fix them.

  is this a sane way to start the process -- just to see where the
older toolchain has problems building the current version of uclibc,
and seeing if there's an obvious fix?  thanks.

rday

-- 

Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA

http://crashcourse.ca

___
uClibc mailing list
uClibc@uclibc.org
http://busybox.net/cgi-bin/mailman/listinfo/uclibc