This is the mail archive of the
glibc-linux@ricardo.ecn.wfu.edu
mailing list for the glibc project.
Re: CrosGCC: [cross]compiling egcs/gcc with glibc headers
- To: glibc-linux at ricardo dot ecn dot wfu dot edu
- Subject: Re: CrosGCC: [cross]compiling egcs/gcc with glibc headers
- From: Brendan John Simon <Brendan dot Simon at ctam dot com dot au>
- Date: Tue, 25 Jan 2000 20:49:27 +1100
- CC: crossgcc <crossgcc at sourceware dot cygnus dot com>
- Organization: CTAM Pty Ltd
- References: <388C407D.27AED07E@ctam.com.au> <388C5B3A.8B7F7691@freenet.hut.fi>
- Reply-To: glibc-linux at ricardo dot ecn dot wfu dot edu
Kai Ruottu wrote:
> Brendan John Simon wrote:
> >
> > I'm trying to cross-compile gcc-2.95.2 and egcs-1.1.2 for a
> > powerpc-linux system. Kai Ruotto suggested preinstalling headers and
> > libs from an exisiting powerpc-linux system (yellowdog) into the
> > $prefix/$target/include and $prefix/$target/lib directory. This does
> > work but I'm not too keen on this method. I'd prefer to compile
> > everything from the sources.
> >
> > I would prefer to use gcc-2.95.2 but it has problems compiling
> > glibc-2.1.1 and glibc-2.1.2. It complains about
> > __libc_global_constructors not being defined. I do not have this
> > problem when I use egcs-1.1.2. This problem shows up for both native
> > ix86-linux compiles and also powerpc-linux cross-compiles. Any ideas ?
>
> I think you must first update your native Linux 'host' suitable for
> glibc-2.1.x before the build will succeed. The same thing will be needed
> for the 'virtual' powerpc-linux 'host'. The minimum can be the Linux
> kernel-2.2.10 or something...
Do you actually install a new kernel or are the kernel headers enough ?
I have been using 2.2.6 for the native compile and 2.2.5 for the cross-compile. I will
probably got 2.2.13 or 2.2.14.
> -------------------- clip ----------------------------------------------
>
> So the gcc-2.95.x seems to be now the 'preferred'...
>
> Ok, some 'stupid' or self-evident questions and things...
>
> Where it gives that "__libc_global_constructors not being defined" ? Which
> compiler it uses then? (The native one because of some error, or the cross-
> compiler and not finding this from the headers...). Or it is a link-error
> when trying to build some executable/shared library? (Is the 'shared' used
> when trying to produce the shared lib?)
This happens with both the native compile AND the cross compile using gcc-2.95.2. I have
just recompiled my native tools (binutils-2.9.5.0.24, egcs-1.1.2) and glibc-2.1.x still
fails. This leads me to believe that is NOT gcc-2.95.2, but binutils-2.95.x (or maybe my
kernel headers ?). I know that people have used binutils-2.9.5 so I will have to find out
which version.
> When the glibc will be built with some compiler, native or cross, there
> SHOULDN'T be any need for other C-headers than those provided with the glibc
> sources, and the build should find the headers from the sources. Just as
> the newlib build will not need any headers for the 'host' (= 'target' with
> other builds). So copying them somewhere is unnecessary. (The Linux kernel
> headers and the target 'asm' headers must be got somewhere however...)
>
> The GCC-build needs the headers for the target, but building the C-library
> should not need them anywhere but in the C-library sources. Old glibc-versions
> (1.09) took some headers from the target's proprietary (from the manufacturer)
> ones and searched some info from them ('sys/errno.h', 'sys/param.h',...).
>
> Building GCC using the new glibc-2.1.x may perhaps work only when the glibc-2.1.x
> has been installed. So you probably need to build gcc-2.95.2 first using your
> current headers & libs, build glibc-2.1.x using it, install glibc-2.1.x and rebuild
> gcc-2.95.2 with glibc-2.1.x. Or the things may be more complicated, I cannot say
> how well (or if at all) old glibc-2.0.7-based binaries will run with glibc-2.1.x
> shared libraries.
This is what am now trying, but egcs now fails when I use binutils-2.9.9.x.
Thanks Kai,
I am emailing the binutils group about the glibc-2.1.2 problems
Brendan Simon.