From: Arnout Vandecappelle <arnout@mind.be>
To: buildroot@busybox.net
Subject: [Buildroot] full rebuild and errors
Date: Wed, 29 Jan 2014 11:42:16 +0100 [thread overview]
Message-ID: <52E8DB08.8060107@mind.be> (raw)
In-Reply-To: <20140129093013.5ca63190@skate>
On 29/01/14 09:30, Thomas Petazzoni wrote:
> Dear Arnout Vandecappelle,
>
> On Wed, 29 Jan 2014 08:14:09 +0100, Arnout Vandecappelle wrote:
>
>>> No, it doesn't. The cache of ccache is located in
>>> ~/.buildroot-ccache/, because the intent of ccache is precisely to be
>>> able to re-use the cache contents across complete rebuilds, and even
>>> across multiple clones of Buildroot.
>>
>> But this is yet another proof that it doesn't work very well. And this
>> one really worries me, because it's a host build that failed.
>
> And for what it worth just two days ago, one of my colleague also had a
> weird compilation problem while building host-gettext (the link step
> was complaining because one of the object file it was given was built
> for i386, while the host machine is x86-64, and therefore the link was
> failing). The problem was reproducible even after a complete 'make
> clean all' cycle. And it turned out that clearing the cache solved the
> problem, so it was indeed a mis re-use of an existing object file.
>
> And it was also on the build of a host package, which is really weird.
> We know that our ccache handling is far from perfect in terms of
> detecting a change of the target compiler, but I wasn't aware of any
> theoretical problem regarding the build of host packages.
If you encounter this again, it would be worthwhile to save the object
file produced by ccache and then to try find where it was originally
produced... CCACHE_LOGFILE can help.
Regards,
Arnout
--
Arnout Vandecappelle arnout at mind be
Senior Embedded Software Architect +32-16-286500
Essensium/Mind http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint: 7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F
next prev parent reply other threads:[~2014-01-29 10:42 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-26 12:07 [Buildroot] full rebuild and errors Marco Trapanese
2014-01-27 17:16 ` Arnout Vandecappelle
2014-01-28 20:24 ` Marco Trapanese
2014-01-28 22:09 ` Thomas Petazzoni
2014-01-29 7:14 ` Arnout Vandecappelle
2014-01-29 8:19 ` Marco Trapanese
2014-01-29 8:30 ` Thomas Petazzoni
2014-01-29 10:42 ` Arnout Vandecappelle [this message]
2014-01-30 13:45 ` [Buildroot] udev and serial port Marco Trapanese
2014-01-30 13:51 ` Gustavo Zacarias
2014-01-30 14:16 ` Marco Trapanese
2014-01-30 17:19 ` Marco Trapanese
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=52E8DB08.8060107@mind.be \
--to=arnout@mind.be \
--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