[uClibc] [PATCH] fix makefile when not cross-compiling.

Rob Landley rob at landley.net
Tue Aug 19 12:37:26 UTC 2003

I'm bashing together my own linux from scratch system using uclibc to 
statically link chapter 5 (because I'm nuts, that's why), and I did this to 
install the Linux headers:

> cd $DESTSRC &&
> tar xvjf $SOURCE/linux-2.4.21.tar.bz2 &&
> cd linux-2.4.21 &&
> make mrproper &&
> make include/linux/version.h &&
> make symlinks &&
> mkdir $DESTSTATIC/usr/include/asm &&
> cp -HR include/asm $DESTSTATIC/usr/include &&
> cp -R include/linux $DESTSTATIC/usr/include &&
> touch $DESTSTATIC/usr/include/linux/autoconf.h &&
> cd / &&
> rm -rf $DESTSRC/linux-2.4.21

I then tell uclibc that "KERNEL_SOURCE=$(DESTSTATIC)/usr", and beat on uclibc like so:

> cd $DESTSRC &&
> tar xvjf $SOURCE/uClibc-0.9.20.tar.bz2 &&
> cd uClibc-0.9.20 &&
> bzcat $SOURCE/uClibc-config.bz2 > .config &&
> yes "" | make oldconfig &&
> make

There's no theoretical reason for this not to work, but I encounter the following error:

> The path '/home/lfs/newfirmware/image/static/usr/include/asm' doesn't exist.
> correctly when you configured uClibc.  Please fix these settings.

Why?  Because even though the destination has a perfectly good include/asm
link, and I'm not cross-compiling, the symlink went to
"$DESTSTATIC/usr/include/asm-i386", which doesn't exist.  (Yeah, I could
make a gratuitious symlink, but honestly...)  The linux-kernel source
itself already has machinery to create this symlink for itself (make
symlinks), and reinventing the wheel here is a bit counterproductive in my

Beyond that, is there any reason it can't use the installed version of the 
kernel header files, when they do happen to be the right ones?  I
explicitly told it where they live, and with a bit of tweaking uClibc can
be made to build against that just fine.

Here's a patch to fix it.  If we're not cross-compiling, and the target has
an asm symlink or directory already, just use it.  (This may even allow
uclibc to compile against the sanitized glibc-headers or some such, I
haven't tried it...)  If you're compiling against a freshly extracted
kernel source tarball, or cross-compiling, the logic should be unchanged.

--- uClibc-old/Makefile 2003-06-30 14:22:43.000000000 -0400
+++ uClibc-0.9.20/Makefile      2003-08-19 08:15:30.849333136 -0400
@@ -120,7 +120,10 @@

 headers: include/bits/uClibc_config.h
        rm -f include/asm;
-       @if [ "$(TARGET_ARCH)" = "powerpc" ];then \
+       @if [ $(CROSS)x == x ] && \
+           [ -f "$(KERNEL_SOURCE)/include/asm/unistd.h" ]; then  \
+               ln -fs $(KERNEL_SOURCE)/include/asm include/asm; \
+       elif [ "$(TARGET_ARCH)" = "powerpc" ];then \
            ln -fs $(KERNEL_SOURCE)/include/asm-ppc include/asm; \
        elif [ "$(TARGET_ARCH)" = "mips" ];then \
            ln -fs $(KERNEL_SOURCE)/include/asm-mips include/asm; \

With that patch, it builds quite nicely (when optimizing for i386.
Optimizing for Pentium II breaks, but that's a separate email. :)

This is also more in the sprit of Linus's old note that /usr/include should
have the headers your libc was compiled against, not the ones for your
currently installed kernel...

On a side note, you'll notice I didn't install asm-generic in my headers.
That's because Red Hat 9 hasn't got it, so it can't be vitally important.
I did a "find . -type f | xargs grep asm-generic" in the uClibc source
code, and the ONLY occurrences of it are A) in the changelog, B) creating
a symlink to it in the makefile.  (Which is a broken symlink on my system,
but it happily builds anyway.)

The changelog says that it's only needed on sparc.  Could that symlink
creation have an architecture-specific if/else around it so that's a little
more obvious?  (I noticed that the LFS guys added it to their 4.1 header
creation without mentioning that on i386 it's unnecessary...)


More information about the uClibc mailing list