[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.
> I bet you did not set KERNEL_SOURCE, TARGET_ARCH or UCLIBC_HAS_MMU
> 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
case.

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...)

Rob





More information about the uClibc mailing list