From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20061 invoked by alias); 10 Nov 2005 09:24:47 -0000 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 Received: (qmail 20040 invoked by uid 22791); 10 Nov 2005 09:24:40 -0000 Received: from fep32-0.kolumbus.fi (HELO fep32-app.kolumbus.fi) (193.229.0.63) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Thu, 10 Nov 2005 09:24:40 +0000 Received: from [10.0.0.3] (really [81.197.132.163]) by fep32-app.kolumbus.fi with ESMTP id <20051110092437.PBIH9722.fep32-app.kolumbus.fi@[10.0.0.3]>; Thu, 10 Nov 2005 11:24:37 +0200 Message-ID: <4373136B.2070603@mbnet.fi> Date: Thu, 10 Nov 2005 09:24:00 -0000 From: Kai Ruottu Reply-To: karuottu@mbnet.fi User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) MIME-Version: 1.0 To: Frank Beesley CC: gcc-help@gcc.gnu.org Subject: Re: Updating powerpc-crosscompile environment from gcc-2.95.3 References: <43725835.4070503@aeroflex.com> <43726A38.4060506@mbnet.fi> <43727695.1090804@aeroflex.com> In-Reply-To: <43727695.1090804@aeroflex.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2005-11/txt/msg00150.txt.bz2 Frank Beesley wrote: > > Lets take one step back - take a look at Kimmo Mustonen's original message: > > .../gcc-4.0.2/configure --target=powerpc-linux --with-cpu=603e --nfp \ > --prefix=/tmp/cross --enable-shared --enable-languages="c" \ > --with-newlib --disable-threads Here we have all kind of "my friend told this could be good to be there"-like things, just as people used to put all kind of things into their CONFIG.SYS and AUTOEXEC.BAT in the good old DOS time... For instance the '--with-newlib' has absolutely nothing to do with a Linux targeted GCC configuration. Linux/PPC is finally quite used system, there are distros like SuSE Linux 10.0/ppc, YellowDog 4.0 (or newer), Fedora Core 3/PPC, Debian and maybe many others Linux/PPC:s freely available and downloadable. So starting from absolute scratch this way has its only motivation in those bolshevism-like ideas, forgotting everything created this far and starting everything from the very beginning. There really isn't any lack of available bootstrap components for Linux/PPC. As this example shows, the GCC build tries to produce the 'libgcc_s.so.1' by linking against the already available target C library, and tries to link simple dummy stubs when configuring the extra libiberty and libstdc++-v3 components. Unless one disables producing the shared libraries. And requires the target headers from the C library when compiling the exception handling routines into the 'libgcc_eh.a'... If one has "some suitable" target C library, the '--enable-shared --enable-threads' can be used, otherwise both must be disabled and the result is a stripped GCC which maybe can or can not compile the C library ok. One cannot be sure about this without very deep understanding about the C library doings... > So we both have just built and installed a new binutils (2.16 for Kimmo, > 2.15 for me) using a native gcc (2.95 for Kimmo, 3.2.2 for me) and we > are now trying to build the first-stage gcc cross-compiler (4.0.2 for > Kimmo, 4.0.1 for me). My suggestion to Kimmo was to change his gcc > configure to remove enable-shared and replace it with disable-shared. > Because of this change I am able to get further through the first-step > gcc cross-compiler build - though is does not successfully complete. As told, the usability of this kind of 'stripped GCC' is not so clear... Anyway I tried this with 'ppc-linux' and got the GCC parts made but without the 'libgcc_eh.a'. And then got glibc-2.3.5 almost made without any extra workarounds. The missing 'libgcc_eh.a' required one and during the 'make install' the 'dlfcn/libdl.so.2' was told to be missing, so one workaround more was needed... I produced stripped GCCs from the unmodified FSF gcc-3.4.4 and gcc-4.0.2 sources and used gcc-3.4.4 to compile the glibc-2.3.5, with the linux-2.6.12.2 kernel headers.. As the alternative I would recommend to everyone in these "bootstrap" cases when there are no self-made components yet, is to use pre-made bootstrap-components. When producing a native GCC people mostly accept a pre-made GCC, pre-made binutils and pre-made glibc for the native target. Only very few try to avoid using them and are therefore obliged to cross-produce these on some non-GNU system which has absolutely no pre-made GNU components, so that one can produce everything from their virgin sources. With a cross-GCC the only required bootstrap component is the "suitable" target C library because the GCC build wants it in order to produce that 'libgcc_s.so.1', the threads and the exception handling support. When the 'complete' stage1 GCC is ready, it can be used to compile the C library. Using this kind of GCC there shouldn't be any troubles and required workarounds at all... I re-made the gcc-3.4.4 using the SuSE Linux 10.0 glibc-2.3.5-40 RPMS (the 'base shared' and the 'devel') as the target C library and built both C and C++ support immediately, including libiberty and libstdc++. And then tried this complete GCC with the glibc-2.3.5 sources and with the linux-2.6.12.2 kernel headers. Now the build went through without any problems. But I didn't (yet) try installing it, so the problem with the missing 'libdl.so.2' could have existed still... Even with a 'just for a fun' crosstoolchain like this, I prefer to know what the target system is, so it producing code which should run ok on SuSE 10.0 is better than it producing code for something which doesn't exist, a 'generic Linux/PPC using generic glibc-2.3.5'... > After I run the gcc configure I run make to build the gcc cross > compiler. This is what is failing with the message that it cannot create > executables - this is from within the make script, and yes I understand > that the "compiler" is not who actually makes the "executable". Maybe you don't try to produce only GCC but also libiberty and libstdc++, which then require the C library to exist... I would be quite sure that the GCC build ('make all-gcc') doesn't try to create any executables with the produced crosscompiler ! If this happens during the GCC build in the 'gcc' subdirectory, please tell where ! > I have > also tried setting my path to $PREFIX/$TARGET/bin:$PATH to point at the > newly built tools but the configure for gcc fails when I do this. So > still have not figured out the right combination to build the gcc cross > compiler. I cannot successfully run "make install-gcc" because I cannot > build gcc for the powerpc-motorola-linux target. For this I can only say that using the "build & install only GCC" commands: make all-gcc make install-gcc should work after using the '--disable-shared --disable-threads' options during the GCC configure... The gcc-4.0.2 and gcc-3.4.4 sources allowed building them without any headers from the C library. But older '3.x' GCCs can require some Linux target headers from glibc with Linux/PPC...