chroot'd toolchain & gnu libc issue? (was Re: Proper use of libtool under buildroot?)

Marcus Crafter crafterm at gmail.com
Mon Dec 12 00:11:14 UTC 2005


Hi Peter,

Thanks for your response mate, much appreciated.

On 11/12/2005, at 10:05 AM, Peter S. Mazinger wrote:

> On Sun, 11 Dec 2005, Marcus Crafter wrote:
>> The problem I'm finding relates to buildroot shared library packages
>> that use "configure" scripts. Usually they're "configure"d as if they
>> are to be installed under /usr - when in reality they're installed to
>> buildroot/buid_xxx/staging_dir and then buildroot/build_xxx/root.
>
> in first case prefix has to be correct, and .la will work correctly  
> (You
> are not allowed to for ex.
> ./configure --prefix=/usr
> make install DESTDIR=buildroot/build_xxx/staging_dir
>
> it has to be
> ./configure --prefix=buildroot/build_xxx/staging_dir

Ok.

> haven't looked buildroot if it does this, I know that uclibc.mk had it
> wrong some time ago

There's a few packages that seem to do this convention of 'configure'  
under /usr but a 'make install' under $(STAGING_DIR). This is what  
actually threw me off thinking I was doing something wrong. Thanks  
for validating what should be 'the right way'.

>
> the second case is problematic, because there you have to use
> ./configure --prefix=/usr and this gets the .la files pointing to
> libdir=/usr/lib.

Yes, this is exactly the problem I was having.

> Some possibilities:
> 1. remove .la files, if the app is written well, it will be linked
> properly indepedently of .la, if not you may add the libs needed  
> seen in
> the .la files
> 2. hack libtool to accept some sort of root=
> 3. build only the minimally needed stuff, then chroot into the dir

Ok.

>
> warning: similar problem is present w/ pkgconfig

Yes, I didn't mention it but you're right - pkgconfig has the same  
symptoms as well.

>
> I opt for 3. chroot/finally usable binaries built natively are much
> better then what you ever will get cross-compiled
>
> If you are trying to get such big apps, you should really go native

Ok, sounds like chroot is the way to go then.

Since I need the compilation tools, etc, available inside of the  
chroot'd environment, I built up a fresh new buildroot environment  
that includes essentially everything using the 'generic dev system'  
board target in buildroot's 'make menuconfig' options.

The only thing is once I chroot into the new environment, all of the  
build related tools from the toolchain don't work because it seems  
that they are linked to libc.so.6 (GNU libc?) which doesn't exist in  
the uclibc root environment right?

eg:

bellagio[/home/crafterm/workspace/new/buildroot/build_i386]:121>sudo  
chroot root
bellagio[/]:1>cd /usr/bin
bellagio[/usr/bin]:2>./i386-linux-uclibc-gcc
bash: ./i386-linux-uclibc-gcc: No such file or directory
bellagio[/usr/bin]:3>ldd ./i386-linux-uclibc-gcc
         libc.so.6 => not found (0x00000000)
         /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x00000000)
bellagio[/usr/bin]:4>ldd ld
         libc.so.6 => not found (0x00000000)
         /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x00000000)
bellagio[/usr/bin]:5>

Have I perhaps built the toolchain incorrectly? Shouldn't they be  
linked against the uclibc libc shared library?

Any thoughts mate?

Cheers,

Marcus



More information about the uClibc mailing list