Trouble compiling MIPS cross-compiler

Trouble compiling MIPS cross-compiler

[Adam Nielsen]

Hi,

I've been following the instructions in the FAQ on linux-mips.org but when I 
go to compile ecgs-1.1.2, half way through I get this error:

as: unrecognized option `-O2'
make[3]: *** [libgcc2.a] Error 1
make[3]: Leaving directory `/home/adam/toinstall/egcs-1.1.2/gcc'

I can post more of the error messages if you need them.  I tried upgrading my 
host binutils as well, but that didn't make a difference.  If I run 
"mips-linux-as -O2" it works, but just "as -O2" gives that same error.  
They're both the same versions now:

$ as -v -O2
GNU assembler version 2.14 (i686-pc-linux-gnu) using BFD version 2.14 20030612
as: unrecognized option `-O2'

$ mips-linux-as -v -O2
GNU assembler version 2.14 (mips-linux) using BFD version 2.14 20030612

Does anyone know how to fix this problem?

Thanks,
Adam.

Re: Trouble compiling MIPS cross-compiler

[Adam Nielsen]

> as: unrecognized option `-O2'

Ok, I just worked out the problem - or at least I discovered a workaround.  If 
I run:

	./configure --prefix=/usr/local [...]

then I get the error during compilation, but if instead I run

	./configure --prefix=/usr [...]

then it appears to work perfectly...!

No idea what's going on, but at least it works and hopefully it won't 
overwrite my existing compiler when I install it ;-)

Cheers,
Adam.

Re: Trouble compiling MIPS cross-compiler

[Thiemo Seufer]

Adam Nielsen wrote:
> > as: unrecognized option `-O2'
> 
> Ok, I just worked out the problem - or at least I discovered a workaround.  If 
> I run:
> 
> 	./configure --prefix=/usr/local [...]
> 
> then I get the error during compilation, but if instead I run
> 
> 	./configure --prefix=/usr [...]
> 
> then it appears to work perfectly...!
> 
> No idea what's going on, but at least it works and hopefully it won't 
> overwrite my existing compiler when I install it ;-)

IIRC you need to configure with AS=mips-linux-as.


Thiemo

Re: Trouble compiling MIPS cross-compiler

[Ralf Baechle]

On Sat, Jan 17, 2004 at 05:36:49PM +1000, Adam Nielsen wrote:

> 	./configure --prefix=/usr [...]
> 
> then it appears to work perfectly...!
> 
> No idea what's going on, but at least it works and hopefully it won't 
> overwrite my existing compiler when I install it ;-)

gcc and binutils must be installed with the same prefix or gcc will not
find the target as and fallback to the native tools which of course
won't work at all as you saw.

In your other mail you mentioned you were using gcc 1.1.2; I recommend
gcc 2.95.4 instead.  gcc 1.1.2 needs a few workarounds in the kernel
source in particular for 64-bit kernels and I've removed all of them
around 2003-05-16 (in the Linux 2.4.20 age) so I'm not sure if egcs 1.1.2
will still work.  Sympthom are compiler core dumps.  Newer doesn't harm ...

  Ralf

Re: Trouble compiling MIPS cross-compiler

[Ralf Baechle]

On Sat, Jan 17, 2004 at 05:27:53PM +0100, Thiemo Seufer wrote:

> > No idea what's going on, but at least it works and hopefully it won't 
> > overwrite my existing compiler when I install it ;-)
> 
> IIRC you need to configure with AS=mips-linux-as.

gcc uses as from the tools by default, then falls back to as in $PATH if
that fails.  So if you have to set the AS variable that's kludging around
the real problem.

  Ralf

Re: Trouble compiling MIPS cross-compiler

[Adam Nielsen]

> In your other mail you mentioned you were using gcc 1.1.2; I recommend
> gcc 2.95.4 instead.  gcc 1.1.2 needs a few workarounds in the kernel
> source in particular for 64-bit kernels and I've removed all of them
> around 2003-05-16 (in the Linux 2.4.20 age) so I'm not sure if egcs 1.1.2
> will still work.  Sympthom are compiler core dumps.  Newer doesn't harm ...

Yes, I saw that in the kernel docs but I tried it anyway since that's the 
version used in the FAQ.  I ended up getting another error though, and 
upgrading to gcc 2.95.3 (couldn't find .4) didn't help:

/usr/mips-linux/bin/as: unrecognized option `-mcpu=r3000'

I saw that this option was removed a while back, so I guess downgrading the 
binutils is the only way to go (or upgrading gcc, but I got a ton of errors 
compiling 3.3.2 so I guess that doesn't work...)

I'll try an older version of the binutils and see if that fixes it.  Thanks 
for your help!

Cheers,
Adam.

Re: Trouble compiling MIPS cross-compiler

[Adam Nielsen]

> I'll try an older version of the binutils and see if that fixes it.

Well, I downgraded to binutils 2.13.2.1 and it got past the -mcpu error, but 
now I get this error instead (I'm compiling a stock 2.6.0 kernel with gcc 
2.95.3):

include/asm/sgidefs.h:18: #error Use a Linux compiler or give up.

followed by hundreds of other various errors.  So I'm stuck again ;-)  Any 
ideas?  I'm guessing I need to get a newer compiler...?

Cheers,
Adam.

Re: Trouble compiling MIPS cross-compiler

[Ralf Baechle]

On Sun, Jan 18, 2004 at 11:54:22AM +1000, Adam Nielsen wrote:

> > I'll try an older version of the binutils and see if that fixes it.
> 
> Well, I downgraded to binutils 2.13.2.1 and it got past the -mcpu error, but 
> now I get this error instead (I'm compiling a stock 2.6.0 kernel with gcc 
> 2.95.3):
> 
> include/asm/sgidefs.h:18: #error Use a Linux compiler or give up.
> 
> followed by hundreds of other various errors.  So I'm stuck again ;-)  Any 
> ideas?  I'm guessing I need to get a newer compiler...?

No, a Linux compiler, not the one from the corn flakes package ;-)

  Ralf

Re: Trouble compiling MIPS cross-compiler

[Eric Christopher]

> 
> /usr/mips-linux/bin/as: unrecognized option `-mcpu=r3000'
> 
> I saw that this option was removed a while back, so I guess downgrading the 
> binutils is the only way to go (or upgrading gcc, but I got a ton of errors 
> compiling 3.3.2 so I guess that doesn't work...)
> 

You do? What errors? How'd you build the toolchain?

At any rate, I'm using gcc and binutils HEAD to build quite a few
things. The last kernel I have is from broadcom (sibyte division) and
rebuilt and booted on the swarm board. (In fact, the compiler also
bootstraps on the board).

-eric

-- 
Eric Christopher <echristo@redhat.com>

Re: Trouble compiling MIPS cross-compiler

[Adam Nielsen]

> You do? What errors? How'd you build the toolchain?

I was just following the linux-mips.org FAQ for building a cross compiler.  
The errors were something to do with missing headers (pthread.h among others) 
so I tried configuring gcc with --disable-threads as suggested in a post 
Google found, and so far that seems to be working...except just as I wrote 
that it came up with this:

/usr/mips-linux/bin/ld: cannot open crti.o: No such file or directory

Now I see why it says on the FAQ that building a cross compiler has always 
been the hardest step - it's certainly a lot harder than you'd expect (at 
least for a cross-compiler newbie like me ;-))  I was thinking it would be a 
simple matter of compiling a few programs in a certain order and that'd be 
it, but it seems that there are huge differences between versions - the 
instructions use ecgs-1.1.2 and binutils-2.13.2.1, but to compile linux-2.6.0 
you need newer than ecgs-1.1.2, but using gcc-3.x means upgrading to 
binutils-2.14, but then when you've done that gcc-3.x won't compile so you 
try gcc-2.95.3 instead, but that means you have to go back to 
binutils-2.13.2.1 but then gcc-2.95.3 is still too old to compile the kernel, 
so you *need* gcc-3.x but that won't compile...grrr!!! ;-)

Cheers,
Adam.

Re: Trouble compiling MIPS cross-compiler

[Eric Christopher]

On Sat, 2004-01-17 at 21:10, Adam Nielsen wrote:
> > You do? What errors? How'd you build the toolchain?
> 

Try this:

http://www.kegel.com/crosstool/

-eric

-- 
Eric Christopher <echristo@redhat.com>

Re: Trouble compiling MIPS cross-compiler

[Kumba]

Adam Nielsen wrote:

> I was just following the linux-mips.org FAQ for building a cross compiler.  
> The errors were something to do with missing headers (pthread.h among others) 
> so I tried configuring gcc with --disable-threads as suggested in a post 
> Google found, and so far that seems to be working...except just as I wrote 
> that it came up with this:
> 
> /usr/mips-linux/bin/ld: cannot open crti.o: No such file or directory
> 
> Now I see why it says on the FAQ that building a cross compiler has always 
> been the hardest step - it's certainly a lot harder than you'd expect (at 
> least for a cross-compiler newbie like me ;-))  I was thinking it would be a 
> simple matter of compiling a few programs in a certain order and that'd be 
> it, but it seems that there are huge differences between versions - the 
> instructions use ecgs-1.1.2 and binutils-2.13.2.1, but to compile linux-2.6.0 
> you need newer than ecgs-1.1.2, but using gcc-3.x means upgrading to 
> binutils-2.14, but then when you've done that gcc-3.x won't compile so you 
> try gcc-2.95.3 instead, but that means you have to go back to 
> binutils-2.13.2.1 but then gcc-2.95.3 is still too old to compile the kernel, 
> so you *need* gcc-3.x but that won't compile...grrr!!! ;-)

I can't guarantee the below will work for you, but it has produced a 
cross-compiler on my sparc64 machine (I now use an i686->mips 
cross-compiler), but the instructions should be easily adaptable.

The commands assume you are building in a separate build directory in 
the source tree (i.e. glibc-x.y.z/buildhere/).

I'd recommend the following:
binutils-2.14.90.0.7 (or you can try the latest .8 release, it has some 
more mips fixes in it)
glibc-2.3.2 (or 2.3.1)
gcc-3.3.2

CVS snaps of latest gcc/glibc/binutils may also work as well.


-------------------

# ${myARCH}: Target Architecture
# ${myHOST}: Build Architecture
# ${myDEST}: Install location
# ${myXTRA}: Arch-specific flags to build glibc with


export myARCH=mips-unknown-linux-gnu
export myHOST=sparc-unknown-linux-gnu
export myDEST=/home/crossdev/mips
export myXTRA="-mips3 -mabi=32"

--- binutils ---
../configure \
	--target=${myARCH} --host=${myHOST} \
	--prefix=${myDEST} --enable-shared \
	--enable-64-bit-bfd \
&& make && make install


--- kernel headers ---
cd ${myDEST}
cp -r /usr/include/* ${myDEST}/include/
rm -Rf ${myDEST}/include/linux
rm -Rf ${myDEST}/include/asm*
cp -r /usr/src/linux/include/linux ${myDEST}/include
cp -r /usr/src/linux/include/asm-$(echo ${myARCH} | cut -d- -f1) 
${myDEST}/include
cp -r /usr/src/linux/include/asm-generic ${myDEST}/include
ln -s ${myDEST}/include/asm-$(echo ${myARCH} | cut -d- -f1) 
${myDEST}/include/asm


--- gcc-bootstrap ---
../configure \
	--prefix=${myDEST} --host=${myHOST} \
	--target=${myARCH} --with-newlib \
	--disable-shared --disable-threads \
	--enable-languages=c --disable-multilib \
	--without-headers \
&& make && make install


--- glibc ---
CC="${myARCH}-gcc" CFLAGS="-O2 ${myXTRA}" \
	../configure \
		--prefix=${myDEST} --host=${myARCH} \
		--build=${myHOST} --without-tls \
		--without-__thread \
		--enable-add-ons=linuxthreads \
		--enable-kernel=2.4.0 --with-gd=no \
		--without-cvs --disable-profile \
		--with-headers="${myDEST}/include" \
	&& make && make install


--- gcc-full ---
../configure \
	--prefix=${myDEST} --target=${myARCH} \
	--host=${myHOST} --disable-multilib \
	--enable-shared --enable-languages="c,c++,ada,f77,objc" \
	--enable-nls --without-included-gettext \
	--with-system-zlib --enable-threads=posix \
	--enable-long-long --disable-checking \
	--enable-cstdio=stdio \
	--enable-clocale=generic \
	--enable-__cxa_atexit \
	--enable-version-specific-runtime-libs \
	--with-local-prefix=${prefix}/local \
	--with-libs="${myDEST}/lib" \
	--with-headers="${myDEST}/${myARCH}/include" \
&& make && make install



--Kumba

-- 
"Such is oft the course of deeds that move the wheels of the world: 
small hands do them because they must, while the eyes of the great are 
elsewhere."  --Elrond

Re: Trouble compiling MIPS cross-compiler

[Adam Nielsen]

> I'd recommend the following:
> binutils-2.14.90.0.7 (or you can try the latest .8 release, it has some
> more mips fixes in it)
> ...
> gcc-3.3.2

Thanks for all the info!  Well, I tried building gcc-3.3.2 with your options 
and that worked (hooray!) but I couldn't find binutils-2.14.90.0.7, the 
closest I could see was 2.14 so I used that.  It all compiled ok, but now 
when I go to compile the kernel I get this error:

cc1: error: invalid option `cpu=r3000'

If I copy the command line and change -mcpu to -march then it works fine, but 
this isn't happening automatically for some reason.  Any ideas?  (I tried 
downgrading to binutils-2.13.xxx but it still gave the error, so I'm guessing 
it's a gcc problem - oh how much easier life would be if they didn't remove 
the -mcpu option somewhere along the way ;-))

Cheers,
Adam.

Re: Trouble compiling MIPS cross-compiler

[Eric Christopher]

> If I copy the command line and change -mcpu to -march then it works fine, but 
> this isn't happening automatically for some reason.  Any ideas?  (I tried 
> downgrading to binutils-2.13.xxx but it still gave the error, so I'm guessing 
> it's a gcc problem - oh how much easier life would be if they didn't remove 
> the -mcpu option somewhere along the way ;-))

Actually, I removed it :)

If you'd like the rant behind it I'll mail it privately.

Anyhow, I've been trying to push for the kernel to use either

a) -march depending on whatever cpu is specified
b) -mtune otherwise (this will generate generic code and then tune for
something)

heck. if you do nothing you'll get mips1 code. It should really default
to mips2 (for things like, say, atomic operations), but no one has made
the change and I don't feel strongly enough since I'm using a 64-bit cpu
and n32 :)

-eric

-- 
Eric Christopher <echristo@redhat.com>

Re: Trouble compiling MIPS cross-compiler

[Eric Christopher]

> -mips[1234] as a synonym), although if you use a recent kernel source 
> tree off linux-mips anoncvs, selecting the right CPU/Machinetype in 
> menuconfig will supply the proper -march/-mipsX commands to the 
> compiler.  You'll also want to pass something like this:

Hey, cool. Glad to hear that.

-eric

-- 
Eric Christopher <echristo@redhat.com>

Re: Trouble compiling MIPS cross-compiler

[Kumba]

Adam Nielsen wrote:

> Thanks for all the info!  Well, I tried building gcc-3.3.2 with your options 
> and that worked (hooray!) but I couldn't find binutils-2.14.90.0.7, the 
> closest I could see was 2.14 so I used that.  It all compiled ok, but now 
> when I go to compile the kernel I get this error:
> 
> cc1: error: invalid option `cpu=r3000'

http://www.kernel.org/pub/linux/devel/binutils/

The 2.14.90.0.X series of binutils is a linux-only release maintained by 
HJ Lu, while the 2.14 version is more or less the official GNU version.

As for the kernel, -mcpu was deprecated in gcc-3.2.x, and totally 
removed in gcc-3.3.x.  You'll want to use the -march option (or 
-mips[1234] as a synonym), although if you use a recent kernel source 
tree off linux-mips anoncvs, selecting the right CPU/Machinetype in 
menuconfig will supply the proper -march/-mipsX commands to the 
compiler.  You'll also want to pass something like this:

make ARCH=mips CROSS_COMPILE=mips-unknown-linux-gnu- <target>

Note: CROSS_COMPILE needs to be set to the CHOST the cross compiler was 
built with, in my cases, I use the extended CHOST form.  The more common 
form is mips[el]-linux (or mips64[el]-linux)

For 2.4, if you want a mips64 kernel, pass ARCH=mips64.  For 2.6, pass 
ARCH=mips and select 64-bit mode in menuconfig (or oldconfig or xconfig)


--Kumba

-- 
"Such is oft the course of deeds that move the wheels of the world: 
small hands do them because they must, while the eyes of the great are 
elsewhere."  --Elrond

Re: Trouble compiling MIPS cross-compiler

[Thiemo Seufer]

Eric Christopher wrote:
> 
> > If I copy the command line and change -mcpu to -march then it works fine, but 
> > this isn't happening automatically for some reason.  Any ideas?  (I tried 
> > downgrading to binutils-2.13.xxx but it still gave the error, so I'm guessing 
> > it's a gcc problem - oh how much easier life would be if they didn't remove 
> > the -mcpu option somewhere along the way ;-))
> 
> Actually, I removed it :)
> 
> If you'd like the rant behind it I'll mail it privately.
> 
> Anyhow, I've been trying to push for the kernel to use either
> 
> a) -march depending on whatever cpu is specified

AFAICS current CVS defaults to that (modulo changing it immediately
afterwards to the generic base arch by an superfluous -mipsX option).

> b) -mtune otherwise (this will generate generic code and then tune for
> something)

Actually, -mtune=r3900 breaks the "generic" part due to an assembler bug
(and did so for a long time).


Thiemo

Unscribe this maillist.

[??(zhufeng)]

Unscribe this maillist,thank you .

Unscribe this maillist.

[??(zhufeng)]

Unscribe this maillist,thank you .

Re: Trouble compiling MIPS cross-compiler

[Adam Nielsen]

> As for the kernel, -mcpu was deprecated in gcc-3.2.x, and totally 
> removed in gcc-3.3.x.  You'll want to use the -march option (or 
> -mips[1234] as a synonym), although if you use a recent kernel source 
> tree off linux-mips anoncvs, selecting the right CPU/Machinetype in 
> menuconfig will supply the proper -march/-mipsX commands to the 
> compiler.

Oh ok then - so what should I do to actually compile a MIPS kernel?  I'd 
rather not have to download an entirely separate kernel source, so should I 
just go back to gcc-3.1.1 that supports -mcpu?

Will kernel 2.6.1 or whatever's next work properly in this respect?  I realise 
that there are plenty of valid reasons for removing -mcpu, but it does create 
a big headache for us users, who just want the darn thing to 'go' ;-)

> You'll also want to pass something like this:
> make ARCH=mips CROSS_COMPILE=mips-unknown-linux-gnu- <target>

Oh ok - yes, I sort of guessed how to do this as it wasn't written anywhere, 
and I used "mips-linux" for everything so all should be well there.

At any rate, I think I'll have to call it a day - it's way too much of a 
hassle just to get a working MIPS cross-compiler, and with all the hoops you 
have to jump through I haven't got any patience left :-(

Thanks for all your help everyone,
Adam.

Re: Trouble compiling MIPS cross-compiler

[Kumba]

Adam Nielsen wrote:


> Oh ok then - so what should I do to actually compile a MIPS kernel?  I'd 
> rather not have to download an entirely separate kernel source, so should I 
> just go back to gcc-3.1.1 that supports -mcpu?
> 
> Will kernel 2.6.1 or whatever's next work properly in this respect?  I realise 
> that there are plenty of valid reasons for removing -mcpu, but it does create 
> a big headache for us users, who just want the darn thing to 'go' ;-)

Get the anonymous cvs info for the linux-mips CVS server from the 
linux-mips.org homepage.  That's the source you want to use for mips 
kernels.  For 2.4, you'll need to checkout the linux_2_4 tag, otherwise 
HEAD will give you 2.6 source.

If you are using a setup that relies on -mcpu, I'd look more at changing 
the setup to use something else, since -mcpu is deprecated in gcc for 
mips for all newer toolchains from 3.3 and beyond.


--Kumba

-- 
"Such is oft the course of deeds that move the wheels of the world: 
small hands do them because they must, while the eyes of the great are 
elsewhere."  --Elrond

Re: Trouble compiling MIPS cross-compiler

[Geert Uytterhoeven]

On Sun, 18 Jan 2004, Adam Nielsen wrote:
> At any rate, I think I'll have to call it a day - it's way too much of a
> hassle just to get a working MIPS cross-compiler, and with all the hoops you
> have to jump through I haven't got any patience left :-(

If you have Debian (use at least testing, not stable):
  - apt-get install toolchain-source
  - Follow the instructions in /usr/share/doc/toolchain-source/README

and you'll have a cross-compiler for whatever supported architecture in less
than an hour (depending on the speed of your host machine, of course).

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

Re: Trouble compiling MIPS cross-compiler

[Eric Christopher]

> > b) -mtune otherwise (this will generate generic code and then tune for
> > something)
> 
> Actually, -mtune=r3900 breaks the "generic" part due to an assembler bug
> (and did so for a long time).

Hard to fix it if I don't know about it :)

What's the bug?

-eric

-- 
Eric Christopher <echristo@redhat.com>

Solving the cross-compiler issue (Was: Trouble compiling MIPS cross-compiler)

[Nathan Field]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 4858 bytes --]

This email is a bit long so here's the short version:
	Building cross tools is basically impossible without knowledge 
which isn't available on the www.linux-mips.org web site
	glibc seems to have obvious syntax errors and won't even compile
	The prebuilt tools referenced in the FAQ are so out of date 
they're useless
	Even tools provided by various commercial Linux vendors are out of 
date (at least what MontaVista lets us see in their preview kits)
	This could all be solved if someone wrote a script to do all the 
work which contains all the logic necessary to get a known set of tools to 
build

I've written a script which will do all the work, but because there are 
failures in building glibc it doesn't work. If someone could help me get 
my script to work it could be used to update the cross compile section of 
the FAQ. The script as it stands is attached. It needs some configuration 
(which is why it exits by default), but if you're trying to build a cross 
compiler you'd better have at least some knowledge of what you're doing.

Here's what it does:
	it wgets specific versions of binutils, gcc and glibc
	it sets some environment variables
	it uncompresses and builds the tools in the "correct" sequence 
with the correct options

There are 2 problems with this script:
	1. It references a specific binutils snapshot which will probably 
go away in a few days
	2. It doesn't f'ing work

That said, here's where things are breaking:

I'm also trying to build a newer cross toolchain since MontaVista doesn't
seem to provide one recent enough to even build the linux_2_4 branch from
the linux-mips cvs repository (it builds, but when I run it on my Malta
board it crashes immediately). I'm coming up against problems that just
seem stupidly obvious... Enough ranting though, here are the details.

Kumba suggested using:
> I'd recommend the following:
> binutils-2.14.90.0.7 (or you can try the latest .8 release, it has some 
> more mips fixes in it)
> glibc-2.3.2 (or 2.3.1)
> gcc-3.3.2
	I couldn't find a version of binutils like that, so I grabbed 
yesterdays snapshot, which builds and runs fine. Then I built the gcc 
bootstrap fine. Then I tried building glibc-2.3.2. That failed when it got 
to stdio-common/sscanf. The declaration of sscanf:

sscanf (s, format)
     const char *s;
     const char *format;

Doesn't match the function, and it should be:

sscanf (const char *s, const char *format, ...)

Does no one even bother to test to see if these things compile before they 
are released? I've had similar syntax error type problems when building 
several older (2.2.x) versions of glibc for PPC.

Anyway, after I fixed that I now get a link failure:

/space1/ndf/linux/mips/tools/glibc-build/elf/ld.so.1: undefined reference 
to `elf_machine_rela.7'

The command which generates this is:

mips-linux-gcc -nostdlib -nostartfiles -o 
/space1/ndf/linux/mips/tools/glibc-build/iconv/iconvconfig  
-Wl,-dynamic-linker=/space1/ndf/demos/malta_linux_reference/embedded/tools/lib/ld.so.1    
/space1/ndf/linux/mips/tools/glibc-build/csu/crt1.o 
/space1/ndf/linux/mips/tools/glibc-build/csu/crti.o `mips-linux-gcc 
--print-file-name=crtbegin.o` 
/space1/ndf/linux/mips/tools/glibc-build/iconv/iconvconfig.o 
/space1/ndf/linux/mips/tools/glibc-build/iconv/strtab.o 
/space1/ndf/linux/mips/tools/glibc-build/iconv/xmalloc.o  
-Wl,-rpath-link=/space1/ndf/linux/mips/tools/glibc-build:/space1/ndf/linux/mips/tools/glibc-build/math:/space1/ndf/linux/mips/tools/glibc-build/elf:/space1/ndf/linux/mips/tools/glibc-build/dlfcn:/space1/ndf/linux/mips/tools/glibc-build/nss:/space1/ndf/linux/mips/tools/glibc-build/nis:/space1/ndf/linux/mips/tools/glibc-build/rt:/space1/ndf/linux/mips/tools/glibc-build/resolv:/space1/ndf/linux/mips/tools/glibc-build/crypt:/space1/ndf/linux/mips/tools/glibc-build/linuxthreads 
/space1/ndf/linux/mips/tools/glibc-build/libc.so.6 
/space1/ndf/linux/mips/tools/glibc-build/libc_nonshared.a -lgcc 
`mips-linux-gcc --print-file-name=crtend.o` 
/space1/ndf/linux/mips/tools/glibc-build/csu/crtn.o
/space1/ndf/linux/mips/tools/glibc-build/elf/ld.so.1: undefined reference 
to `elf_machine_rela.7'

Interestingly when I try glibc 2.3.1 I get the same syntax error in sscanf 
but the linker complains about elf_machine_rela, without the .7.

It would be wonderful if I could get some help on this. It seems like a
chicken and egg problem which will only get worse as more and more people
try to build the 2.6 kernels.

	nathan

PS. This script is totally ripped off of Kumba's script which he submitted 
earlier. I've just added stuff to try to automate *everything*.

-- 
Nathan Field (ndf@ghs.com)			          All gone.

But the trouble with analogies is that analogies are like goldfish:
sometimes they have nothing to do with the topic at hand.
        -- Crispin (from a posting to the Bugtraq mailing list)


[-- Attachment #2: Type: APPLICATION/x-sh, Size: 4622 bytes --]

Re: Solving the cross-compiler issue (Was: Trouble compiling MIPS cross-compiler)

[Daniel Jacobowitz]

On Wed, Jan 21, 2004 at 06:32:23PM -0800, Nathan Field wrote:
> This email is a bit long so here's the short version:
> 	Building cross tools is basically impossible without knowledge 
> which isn't available on the www.linux-mips.org web site
> 	glibc seems to have obvious syntax errors and won't even compile
> 	The prebuilt tools referenced in the FAQ are so out of date 
> they're useless
> 	Even tools provided by various commercial Linux vendors are out of 
> date (at least what MontaVista lets us see in their preview kits)

Try a different preview kit.  I'm told that some of the MIPS preview
kits were updated for 3.0 and some weren't, and that's all I know about
that.

> 	This could all be solved if someone wrote a script to do all the 
> work which contains all the logic necessary to get a known set of tools to 
> build
> 
> I've written a script which will do all the work, but because there are 

You _HAVE_ looked at crosstool, right?  Which does all of this, and
does work?

> sscanf (s, format)
>      const char *s;
>      const char *format;
> 
> Doesn't match the function, and it should be:
> 
> sscanf (const char *s, const char *format, ...)
> 
> Does no one even bother to test to see if these things compile before they 
> are released? I've had similar syntax error type problems when building 
> several older (2.2.x) versions of glibc for PPC.

Come on, think.  Glibc 2.3.2 was released before GCC 3.3.  It built at
the time; if you use GCC 3.2 that will compile.  If you want to use GCC
3.3, then use a newer CVS snapshot of glibc.  Which I recommend, but is
still not for the faint of heart.  If you're just trying to build a
kernel as you said later, why are you building glibc anyway?

> Anyway, after I fixed that I now get a link failure:
> 
> /space1/ndf/linux/mips/tools/glibc-build/elf/ld.so.1: undefined reference 
> to `elf_machine_rela.7'

Google will be delighted to explain the controversy of
-finline-limit-10000 to you.  Or use crosstool :)

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: Solving the cross-compiler issue (Was: Trouble compiling MIPS cross-compiler)

[Kumba]

Nathan Field wrote:

> This email is a bit long so here's the short version:
> 	Building cross tools is basically impossible without knowledge 
> which isn't available on the www.linux-mips.org web site
> 	glibc seems to have obvious syntax errors and won't even compile
> 	The prebuilt tools referenced in the FAQ are so out of date 
> they're useless
> 	Even tools provided by various commercial Linux vendors are out of 
> date (at least what MontaVista lets us see in their preview kits)
> 	This could all be solved if someone wrote a script to do all the 
> work which contains all the logic necessary to get a known set of tools to 
> build
> 
> I've written a script which will do all the work, but because there are 
> failures in building glibc it doesn't work. If someone could help me get 
> my script to work it could be used to update the cross compile section of 
> the FAQ. The script as it stands is attached. It needs some configuration 
> (which is why it exits by default), but if you're trying to build a cross 
> compiler you'd better have at least some knowledge of what you're doing.
> 
> Here's what it does:
> 	it wgets specific versions of binutils, gcc and glibc
> 	it sets some environment variables
> 	it uncompresses and builds the tools in the "correct" sequence 
> with the correct options
> 
> There are 2 problems with this script:
> 	1. It references a specific binutils snapshot which will probably 
> go away in a few days
> 	2. It doesn't f'ing work
> 
> That said, here's where things are breaking:
> 
> I'm also trying to build a newer cross toolchain since MontaVista doesn't
> seem to provide one recent enough to even build the linux_2_4 branch from
> the linux-mips cvs repository (it builds, but when I run it on my Malta
> board it crashes immediately). I'm coming up against problems that just
> seem stupidly obvious... Enough ranting though, here are the details.
> 

I also coded my own cross-compiler script, which is partially integrated 
with gentoo's package management system, portage.  It uses the portage 
API to determine the most recent version, download, and patch sources, 
then the script takes over the building process.  It's not flawless, but 
it does work for generating mips[el] cross-compilers on i686 and 
linux-sparc64 hosts (among other targets).

If anyone runs gentoo, it's available as sys-devel/crossdev in the 
portage tree.


> Kumba suggested using:
> 
>>I'd recommend the following:
>>binutils-2.14.90.0.7 (or you can try the latest .8 release, it has some 
>>more mips fixes in it)
>>glibc-2.3.2 (or 2.3.1)
>>gcc-3.3.2
> 
> 	I couldn't find a version of binutils like that, so I grabbed 
> yesterdays snapshot, which builds and runs fine. Then I built the gcc 
> bootstrap fine. Then I tried building glibc-2.3.2. That failed when it got 
> to stdio-common/sscanf. The declaration of sscanf:

That version of binutils is a linux-only release maintained by HJ Lu. 
He even announces new versions to this list.  You can find all the 
versions of this specific branch of binutils at:
http://www.kernel.org/pub/linux/devel/binutils/


> sscanf (s, format)
>      const char *s;
>      const char *format;
> 
> Doesn't match the function, and it should be:
> 
> sscanf (const char *s, const char *format, ...)
> 
> Does no one even bother to test to see if these things compile before they 
> are released? I've had similar syntax error type problems when building 
> several older (2.2.x) versions of glibc for PPC.

This was a bug in early versions of glibc I believe, and is fixed in any 
modern glibc checkout you do from the libc-alpha CVS.


> Anyway, after I fixed that I now get a link failure:
> 
> /space1/ndf/linux/mips/tools/glibc-build/elf/ld.so.1: undefined reference 
> to `elf_machine_rela.7'
> 
> The command which generates this is:

[snip]

> Interestingly when I try glibc 2.3.1 I get the same syntax error in sscanf 
> but the linker complains about elf_machine_rela, without the .7.
> 
> It would be wonderful if I could get some help on this. It seems like a
> chicken and egg problem which will only get worse as more and more people
> try to build the 2.6 kernels.

Another glibc bug, also fixed in modern CVS.  The patch that does fix 
the issue is here:
http://honk.physik.uni-konstanz.de/linux-mips/glibc/patches/applied/elf-machine-rela-mips.dpatch



--Kumba

-- 
"Such is oft the course of deeds that move the wheels of the world: 
small hands do them because they must, while the eyes of the great are 
elsewhere."  --Elrond