[Buildroot] uClibc, gcc get rebuilt on every make

Zac Wheeler zac.wheeler at gmail.com
Thu Jul 2 20:38:23 UTC 2009


On Tue, Dec 9, 2008 at 10:23 AM, Patrick McNeil <patrick at phidgets.com>wrote:

> I'm using svn24232, arm920t, with gcc and headers on the target. Every time
> I run make, even if I haven't made any changes, the cross compiler
> toolchain, as well as the target gcc, and uClibc gets rebuilt, taking about
> half an hour. Any ideas what this is depending on? I know that buildroot
> from a few months ago did not do this.
>

Just in case the issue is still there, this is what I did to resolve it:

diff --git a/toolchain/uClibc/uclibc.mk b/toolchain/uClibc/uclibc.mk
index c8da464..6dff66c 100644
--- a/toolchain/uClibc/uclibc.mk
+++ b/toolchain/uClibc/uclibc.mk
@@ -481,7 +482,7 @@ uclibc-menuconfig: host-sed $(UCLIBC_DIR)/.config
        touch -c $(UCLIBC_DIR)/.config


-$(STAGING_DIR)/usr/lib/libc.a: $(UCLIBC_DIR)/lib/libc.a
+$(STAGING_DIR)/usr/lib/libc.a: $(UCLIBC_DIR)/.configured $(gcc_initial)
$(LIBFLOAT_TARGET)
 ifneq ($(BR2_TOOLCHAIN_SYSROOT),y)
        $(MAKE1) -C $(UCLIBC_DIR) \
                PREFIX= \

This also fixes the issue you sent in another mail where libc.a would get
modified after the initial build and so simply typing "make" again was
enough to break symbols in libc.a (e.g. python's division).

The better way would probably to figure out what is touching
$(UCLIBC_DIR)/lib/libc.a after the initial build and fix that so that make
doesn't see a dependency that is newer than the
$(STAGING_DIR)/usr/lib/libc.a target, but I'm not sure that is easily
possible given the build sequence.

Zac
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20090702/ede55513/attachment.html>


More information about the buildroot mailing list