none none wrote:
> My target system is a powerpc running linux-2.2.
But this has no 'glibc' yet installed in it, the '/lib', '/usr/lib' and
'/usr/include' on the Linux-2.2 system are
mainly empty? An usual cross GCC for something uses the prebuilt target
C library "as it is", copied onto
the cross host, nowadays onto some $sysroot (please see later)...
In that Ubuntu/PPC case installing its prebuilt glibc below some
$sysroot would be one of the prerequisites
before starting to build GCC....
When starting from absolute scratch - no Linux etc. on the target system
- one must use some bootstraping
methods like using a glibc from some "similar system" - a glibc made for
Linux/PPC in your case, or some
"bolshevism" like the "crosstool" when for some political reasons not
accepting any prebuilt "bootstrap"
components ("Don't use anything the capitalism has created, start
everything from absolute scratch!")....
> So in order to build glibc I got the kernel from kernels.org and
unpacked it.
You mean that you also downloaded some (maybe newer) Linux kernel in
order to get the kernel headers,
'include/linux' and 'include/asm*' ? The target system didn't have any
although it had Linux?
> Then I configure with the command:
> configure --prefix=/home/idipous/powerpc/
When one builds glibc, one of the mail goals is to install it onto the
target system, to serve as the "runtime
libraries" there. Linux usually has its runtime in '/lib' and
'/usr/lib' and in this "usual" case the $prefix is fixed
to be '/usr', so usually '--prefix=/usr' in the glibc configure. One
shouldn't think where to put the built glibc
on the cross host but where to put it on the target host ! When needing
to install onto the cross host, one
uses the "install_root=$sysroot" option to put the alien glibc below
some chosen $sysroot, for instance
'/opt/host-powerpc-linux/', onto '$sysroot/lib', '$sysroot/usr/lib',
'$sysroot/usr/include' etc. From this
$sysroot it is then easy to make a 1-to-1 copy onto the target system....
When configuring the cross binutils and cross GCC, there is that new
'--with-sysroot=$sysroot' which
puts the binutils (mainly 'ld') and GCC to search the target C library
below the $sysroot....
--target=powerpc-linux --host=powerpc-linux --enable-add-ons=linuxthreads --with-headers=/home/idipous/powerpc/linux/include/asm-ppc
The '--with-headers=the_dir' should point to the 'include' where the
kernel headers are, not to the
'include/asm' ! So the usual case is using
'--with-headers=$sysroot/usr/include' after copying the
Linux kernel headers onto the chosen '$sysroot/usr/include/linux' and
'$sysroot/usr/include/asm*'....
--with-binutils=/home/idipous/powerpc/bin/home/idipous/Desktop/linux/include/linux
?????? The 'binutils' are binaries running on the cross host....
configure: error: GNU libc requires kernel header files from
Linux 2.0.10 or later to be installed before configuring.
I think that the 'include/linux/version.h' will be checked for the Linux
kernel version...
The kernel header files are found usually in /usr/include/asm and
/usr/include/linux; make sure these directories use files from
Linux 2.0.10 or later. This check uses <linux/version.h>,
and here it was told....
What I am doing wrong? is that the correct header files? Should I do something more or else than just copy them and point the configure script to them?
Let's hope my explanations gave you some clues...
BTW, if your goal only is to build a cross GCC with which to produce
apps and tools being run
on the target system, and the the target system already has its own,
maybe "custom", glibc, then
you shouldn't (need to) rebuild the glibc for the cross host, only copy
it there! In any remote
debugging case it is necessary to have identical runtimes on both the
remote target and the cross
host running the remote debugger ! A function in another address on the
target system than it is
seen on the runtime libraries on the cross host, is a serious "clash"
between these two systems...
