Install problem (Cross compile AVR32)

[Rob Landley]

On Tuesday 21 October 2008 19:57:19 Jeremy Bowen wrote:
> On Wednesday 22 October 2008 12:52:07 pm John Voltz wrote:
> > I would recommend you save yourself the pain, and just use buildroot.
>
> <rant>
> Argh! Why is the world full of lemmings. "buildroot" is not the magical
> answer to life the universe and everything. When something goes wrong with
> buildroot it is virtually impossible to determine WTF it is doing.

That's why I did my Firmware Linux build system, which is implemented as a 
series of bash scripts.  When something goes wrong (not if: when), it's a 
shell script.  You can see exactly what it's doing.

I don't currently have an AVR32 target, because I'm focusing on what qemu 
supports.  Is there an emulator for this platform, or do you need real 
hardware to be able to test the result?

> Additional information.
> ==================
> A colleague and I are trying to sort out our build environments. He's using
> buildroot and it results in a broken (non-booting) linux kernel. I'm NOT
> using buildroot and my kernel is fine but I can't compile applications.
>
> $deity only knows what part of the buildroot chain is broken here so I'm
> trying to independently resolve the toolchain issue and hopefully identify
> exactly which component is broken.

I can't help you with buildroot.  I never know what it's doing either.

> > Save your time and use buildroot. Spend your
> > spare time enjoying a beer or something more enjoyable... ;) You will
> > also inevitably encounter a package with broken configure (or none at
> > all) in which case you better break out a can of patience, because you'll
> > need it!
>
> If I get my toochain fixed and working correctly I can confidently say I
> will NEVER have a problem with broken packages or configure scripts. This
> is entirely independent of whether I use buildroot or not.

Never?  I've had problems with broken packages and configure scripts natively 
compiling on x86.  (Then I have a knack for breaking stuff.  I've 
broken "echo" in more than one way.)

In general, I've found cross compiling to be a minefiled, and native compiling 
sucks way less.  YMMV.

Perhaps you mean when it breaks you can fix it without needing to come to this 
list? :)

> I'm pretty sure this is just a simple configuration setting in either gcc
> or uClibc because at some point over the past few days I was able to build
> executables but I have subsequently changed a setting somewhere.

Lemme look at your original bug report...

> I have the following in my .config
> # Library Installation Options
> #
> SHARED_LIB_LOADER_PREFIX="/lib"
> RUNTIME_PREFIX="/"
> DEVEL_PREFIX="/usr/local/avr32"
>
>
> uClibc appears to build OK. I have attempted to install this using:
> make install PREFIX=/usr/local/avr32/ RUNTIME_PREFIX= DEVEL_PREFIX=

I build and install in the same pass, ala:

make CROSS="${ARCH}-" KERNEL_HEADERS="${CROSS}/include" PREFIX="${CROSS}/" \
     RUNTIME_PREFIX=/ DEVEL_PREFIX=/ all install-runtime install-dev

I remember that the prefixes need to be "/" instead of blank in order for 
things to work out properly...

> cannot find lib/libc.so.0

The compiler starts by looking for /usr/lib/libc.so, which is usually a linker 
script that tells it to go find other things.  If your prefixes didn't have / 
then the uClibc installer (which I patch _out_ with the attached patch 
because it shouldn't be doing this) may be putting relative paths in there.

If you just have _filenames_ in the linker script (which is what you get with 
my patch) then it'll follow the normal library path logic to find them.  If 
you have paths, it won't look in the library paths.  If you have _relative_ 
paths, it'll try to find them relative to whatever directory you currently 
are in, which is broken.

I'm interested in having my firmware linux project make an avr32 toolchain if 
A) it can be built from normal gcc/binutils (applying a patch is ok as long 
as it doesn't screw up other architectures), B) I can get some kind of test 
environment to run the result in.

Rob
-------------- next part --------------
A non-text attachment was scrubbed...
Name: alt-uClibc-install.patch
Type: text/x-diff
Size: 1407 bytes
Desc: not available
Url : http://lists.busybox.net/pipermail/uclibc/attachments/20081023/56500b3e/attachment.bin