SHADOW problem and patches

[Rob Landley]

On Thursday 28 December 2006 5:57 pm, Denis Vlasenko wrote:
> On Thursday 28 December 2006 15:56, Aurelien Jacobs wrote:
> > On Thu, 28 Dec 2006 10:19:54 +0100
> > Marc Leeman <marc.leeman at gmail.com> wrote:
> > 
> > > Some files need shadow_.h (without having
> > > ENABLE_FEATURE_SHADOWPASSWDS).
> > 
> > Including shadow_.h without having ENABLE_FEATURE_SHADOWPASSWDS
> > is wrong. It won't work on systems which don't have shadow.h installed
> > (uClibc systems with shadow password disabled).
> 
> I want to be able to compile busybox against uclibc
> so I can fix/test fixes myself.

I made my own cross compiler, and I made a shell script that does it so it's 
really easy to see what the steps are.

The build scripts are linked from "http://landley.net/code/firmware", you can 
download either the 0.1.0 tarball or the current hg snapshot, run "./build.sh 
i686" and wait a loooong time.  Results wind up in the "build" directory.  
(Or you can download the prebuilt tarballs of the cross-compilers for i686 
and for arm, and and the native build environment for i686, but where's the 
fun in that?  Haven't done x86-64 yet but I'm working on it, and since it's a 
cross-compiler it should work fine for you to build a 32-bit version and use 
that.  It provides all the 32-bit libraries you need.)

In the build directory it should create two tarballs: one is a cross compiler 
you can extract into any directory your like, add the "bin" under that to 
your $PATH, and call i686-gcc (or build busybox with cross prefix "i686-") to 
cross compile stuff stuff against uClibc.

The other tarball is a native build environment you can chroot into and build 
stuff against uClibc with a native toolchain, as normal gcc. (Although it's a 
very sparse Linux From Scratch style build environment and you'll have to 
either install /lib/ld-uClibc.so.0 in the normal location or "export 
UCLIBC_DYNAMIC_LINKER=/tools/lib/ld-uClibc.so.0" before you can run anything 
you build.)

> uclibc FAQ says that I need to build cross-compiler fot that.
> Well that's sort of overkill, but anyway I tried recommended
> method (buildroot). No go

If you don't build a cross-compiler you wind up with libgcc leaking references 
to libc.so.6 into your programs.  Did I mention that gcc is brittle and 
overcomplicated?

I'm using an updated version of the old wrapper script to make the toolchain 
relocatable (that's why you can extract it into your home directory and it 
should work, despite that not being the location I built it at).  But I'm 
still building a cross compiler anyway.  Possibly you could just grab my 
wrapper script and stick it on the front of your exiting compiler (you'll 
need to link gcc-unwrapped to the old one so the wrapper can call it).  It's 
all in my mercurial tree.

http://landley.net/code/firmware

I've also used the arm cross compiler to build a statically linked armv4l 
version of busybox, for testing purposes.  It runs under qemu-arm just fine 
(which the build system also builds).

Rob
-- 
"Perfection is reached, not when there is no longer anything to add, but
when there is no longer anything to take away." - Antoine de Saint-Exupery