From: Bernhard Reutner-Fischer <rep.dot.nop@gmail.com>
To: buildroot@busybox.net
Subject: [Buildroot] uClibc, gcc get rebuilt on every make
Date: Thu, 2 Jul 2009 23:07:47 +0200 [thread overview]
Message-ID: <20090702210747.GE14135@mx.loc> (raw)
In-Reply-To: <206b9e70907021338s137bdb6fw35e4f35bf38581e4@mail.gmail.com>
On Thu, Jul 02, 2009 at 01:38:23PM -0700, Zac Wheeler wrote:
>On Tue, Dec 9, 2008 at 10:23 AM, Patrick McNeil <patrick@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)
This doesn't sounds clean to me. My current working theory:
http://repo.or.cz/w/buildroot.git?a=blob;f=toolchain/uClibc/uclibc.mk;h=5b4e0c6a02daff5a5c498a2d277eb628ca15aad5;hb=HEAD#l509
http://repo.or.cz/w/buildroot.git?a=blob;f=toolchain/uClibc/uclibc.mk;h=5b4e0c6a02daff5a5c498a2d277eb628ca15aad5;hb=HEAD#l550
Again, i invite people to port improvements from my tree to the repo..
HTH,
>$(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
>_______________________________________________
>buildroot mailing list
>buildroot at busybox.net
>http://lists.busybox.net/mailman/listinfo/buildroot
next prev parent reply other threads:[~2009-07-02 21:07 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-12-09 17:23 [Buildroot] uClibc, gcc get rebuilt on every make Patrick McNeil
2009-07-02 20:38 ` Zac Wheeler
2009-07-02 21:07 ` Bernhard Reutner-Fischer [this message]
2009-07-02 23:37 ` Zac Wheeler
2009-07-03 7:11 ` Bernhard Reutner-Fischer
-- strict thread matches above, loose matches on Subject: below --
2009-07-05 13:12 bogus
2009-07-05 18:56 ` Zac Wheeler
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20090702210747.GE14135@mx.loc \
--to=rep.dot.nop@gmail.com \
--cc=buildroot@busybox.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox