[uClibc]buildroot: building the dev environment to run on the target

Erik Andersen andersen at codepoet.org
Tue Mar 4 08:01:22 UTC 2003


On Mon Mar 03, 2003 at 05:18:29PM -0800, David Wuertele wrote:
> First, I just have to say buildroot rocks!  Thanks Erik!

You are welcome!

> It seems that the gcc_target.mk (and many of the other .mk files)
> cause configure to guess the wrong build architecture.  It looks like

I have been primarily building thing natively, rather than cross
compiling.  But I agree it does need to be fixed.

> the build system is the same as the host system.  I found that by
> changing every instance of the execution of ./configure in the .mk
> files from:
> 
>            .../configure \
> 		--target=$(GNU_TARGET_NAME) \
> 
> to
> 
>            .../configure \
> 		--build=i686-pc-linux-gnu \
> 		--host=$(GNU_TARGET_NAME) \
> 		--target=$(GNU_TARGET_NAME) \

You shouldn't need to specify --build but I guess it doesn't hurt
to be really overly extra specific, since the GNU configure
system can sometimes make awfully stupid guesses.

> EXCEPT for the uclibc_toolchain.mk file.  In the case of the
> toolchain, the host and the build arch are the same, so in the
> uclibc_toolchain.mk file I changed it to:
> 
>            .../configure \
> 		--build=i686-pc-linux-gnu \
> 		--host=i686-pc-linux-gnu \
> 		--target=$(GNU_TARGET_NAME) \
> 
> This all appears to work fine for me up until the gcc-target/Makefile
> tries to run 'mipsel-linux-gcc -dumpspecs > tmp-specs'.  There is no
> mipsel-linux-gcc, and even if there were, it isn't what I would
> expect.  I would have expected it to want to run mipsel-uclibc-gcc at
> this point.  Why is it running mipsel-linux-gcc?

Welcome to the world of buggy configure scripts....  I must have
built the toolchains about 500 times trying to come up with a
combination that actually works.  Do the uclibc_toolchain.mk not 
build for you as-is?  I know they work as-is when cross compiling
for arm, though I havn't tried with mipsel recently.

> My second issue with buildroot is that ranlib doesn't get discovered
> properly by the various ./configure scripts.  I added 

Again the result of buggy configure scripts.  Grumble.  I've
certainly seen this happen.

>         CC=$(TARGET_CC) RANLIB=$(TARGET_RANLIB) \
> 	./configure \
> 
> That did the trick.  Again, I don't know how this could work any other
> way.  Did I misconfigure anything?

Perhaps I really need to add a generalized CONFIGURE variable
that sets all the possible toolchain pieces correctly.

> Aside from these two issues with the buildroot makefiles, there were
> of course some issues inside various of the packages where the
> configure script tries to run a program compiled for the target.  In

Yeah.  Openssh is especially bad about this.  I've got it on
my TODO list to teach openssh to cross-compile properly,

 -Erik

--
Erik B. Andersen             http://codepoet-consulting.com/
--This message was written using 73% post-consumer electrons--



More information about the uClibc mailing list