From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29413 invoked by alias); 17 Apr 2006 23:00:26 -0000 Received: (qmail 29381 invoked by uid 22791); 17 Apr 2006 23:00:18 -0000 X-Spam-Check-By: sourceware.org Received: from pne-smtpout3-sn2.hy.skanova.net (HELO pne-smtpout3-sn2.hy.skanova.net) (81.228.8.111) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 17 Apr 2006 23:00:09 +0000 Received: from [10.0.0.3] (84.248.179.139) by pne-smtpout3-sn2.hy.skanova.net (7.2.070) id 43CE14DF00442EAA; Tue, 18 Apr 2006 01:00:05 +0200 Message-ID: <4444204D.2040906@mbnet.fi> Date: Mon, 17 Apr 2006 23:00:00 -0000 From: Kai Ruottu User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: sp4rc CC: gcc-help@gcc.gnu.org Subject: Re: building a crosscompiler drives me mad References: <1145116003.7891.17.camel@uranos.pentacon.gov> <85e0e3140604152343h7cc46d12o981a829283e5dc14@mail.gmail.com> In-Reply-To: <85e0e3140604152343h7cc46d12o981a829283e5dc14@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gcc-help-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-help-owner@gcc.gnu.org X-SW-Source: 2006-04/txt/msg00170.txt.bz2 Niklaus kirjoitti: > On 4/15/06, sp4rc 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...