[uClibc] [PATCH] fix makefile when not cross-compiling.
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 &&
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
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 @@
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