Re: building a crosscompiler drives me mad

[Kai Ruottu <karuottu at mbnet dot fi>]

Niklaus kirjoitti:
> On 4/15/06, sp4rc <sammyshome@gmx.net> wrote:
>   
> > Dear list-members and gcc-gurus,
> >
> > I am trying to build a crosscompiler on a NetBSD 3.0 (i386) system for a
> > Gentoo Linux (i386) system. These are the steps I have performed.
> >
> > [+] The versions I am using:
> > binutils-2.15
> > gcc-3.4.5
> > glibc-2.3.5
> >     
The "Gentoo Linux" most probably already has a built & tested 
glibc-2.3.5 for it !  Or then it is totally
different from Red Hat & Fedora, SuSE, Mandriva, Debian, Ubuntu etc. 
usual "Linux distros"...
> > linux-2.6.8
> >     
Where you think to require the Linux kernel headers and why the Gentoo 
Linux doesn't provide them is
also quite weird...   RedHat&Fedora has had them in a 
'kernel-headers-x.y.z.rpm' package, SuSE and
Debian have these included into the glibc packages.

> Binutils should build without a problem.
> 1) Binutils
>   

My advice for the next step would be :

2. copy the Gentoo Linux's own binary 'glibc-2.3.5' packages into your 
NetBSD host and install the "target C
    library" in them into the same place where the target binutils are 
now (in 'bin' there).  This is the '$tooldir' ,
    which is the same as '$prefix/$target'...

> 2) Copy linux headers  after you do make config. This is important
> because certain files are generated i think. Also you have to copy
> asm-i386, asm-generic , linux inside include .

Copying the whole "target C library", all headers, libraries and 
startups from 'glibc-2.3.5', 'glibc-devel-2.3.5'
etc. packages for the target should be quite usual practice with all the 
Linux (distro) target crosscompilers...

> then you have to do make install-headers for glibc. that is copying
> the proper headers from glibc.
>
> then build the  gcc stage1.
> then build glibc with gcc-stage1.
> Then build gcc-stage2.
>
> I find you not copying asm-generic. Also you want to look at
> crosstool.sh of Dan kegel's crosstool. It is all automated in it.
>   
Automated "bolshevism"?   This expects the target system being totally 
unexisting.  Or being totally neglected
as if it never had existed.  The original bolsheviks had this idea about 
not using anything from the bad capitalism,
creating a better and perfect world from absolute scratch....  I have 
always wondered where this "from scratch"
starts from.... NetBSD has sources for its GCC, its C library, tools 
etc. so maybe one should start on a system
which absolutely has no "pristine sources" for anything, so nothing 
could require this "build from pristine sources"
approach...  The usual explanation afterwards for the miserable failures 
(millions died in hunger etc.) has been
that "the idea was good but the implementation was bad" for the original 
bolshevism...  We will see how long
this new bolshevism will stay and people continue to believe in it...

So instead of thinking that the Gentoo Linux doesn't yet exist and 
therefore everything for it should be built from
scratch, one could think that there are no sources available for 
anything the Gentoo Linux has, so one must be
happy with the available binaries for Gentoo Linux, its glibc-2.3.5 
binaries, its X11 libraries binaries, its Gnome
libraries binaries, whatever libraries one thinks to need in the 
crosstoolchain for Gentoo Linux...  This would be
the case if the target would be AIX, HP-UX, Irix or some other 
commercial Unix... No sources for their own libs.

That Linux has its shared libs mainly in '/lib' but the startups and 
static libs in '/usr/lib', can be a small problem, but
when one sees that almost everything in '/lib' was symlinked to be seen 
in '/usr/lib', then putting stuff for both into
the '$prefix/$target/lib' shouldn't be that hard.  Or first unpacking a 
"1:1" image for the native glibc install  below
some '$sysroot', into 'lib', 'usr/lib', 'usr/include' etc. there.  My 
standard $sysroot name is '/opt/host-$target', for
instance '/opt/host-i686-gentoo-linux' with this "Gentoo Linux/x86" case 
could be my choice.  And then symlink
the '/opt/host-i686-gentoo-linux/usr/include' and 
'/opt/host-i686-gentoo-linux/usr/lib' to be seen as the
'$prefix/i686-gentoo-linux/include' and '$prefix/i686-gentoo-linux/lib' 
because the crosscompiler searches the
target headers and libraries from them....

One existing (and long-standing) GCC bug requires the target headers 
being seen also in the
'$prefix/$target/sys-include'  (although the GCC manuals have told the 
'include' being enough) during the GCC
build (not after its installation), but this is another issue.  
Basically the target stuff (binutils, headers, libs) being
below the '$prefix/$target' in 'bin', 'include' and 'lib' should be 
enough and the GCC build should succeed....
Furthermore the Linux's 'libc.so' is somehow "one eyed" and expects only 
native installations and therefore has
'/lib/libc.so.6 /usr/lib/libc_nonshared.a' there, so one must edit the 
absolute pathnames away and leave only the
file names into a 'libc.so' used in a crosstoolchain...