[Buildroot] [PATCH] ruby: fix verconf.h related build failure
ps.report at gmx.net
Mon Dec 8 12:07:50 UTC 2014
> Gesendet: Montag, 08. Dezember 2014 um 10:34 Uhr
> Von: "Thomas Petazzoni" <thomas.petazzoni at free-electrons.com>
> An: "Peter Seiderer" <ps.report at gmx.net>
> Cc: buildroot at busybox.net
> Betreff: Re: [Buildroot] [PATCH] ruby: fix verconf.h related build failure
> Dear Peter Seiderer,
> On Sat, 6 Dec 2014 00:23:35 +0100, Peter Seiderer wrote:
> > See  for failure analysis.
> > Fixes:
> > http://autobuild.buildroot.net/results/c94fef5d2cfb00a336905ae3c110d7680f6d5416/
> > http://autobuild.buildroot.net/results/4375cb1e325a336dbf59f22f975be9165ad0648a/
> >  http://lists.busybox.net/pipermail/buildroot/2014-December/114273.html
> > Signed-off-by: Peter Seiderer <ps.report at gmx.net>
> > ---
> > package/ruby/ruby.mk | 7 +++++++
> > 1 file changed, 7 insertions(+)
> Thanks for this patch. I had a look, and did some testing. It appears
> that the issue doesn't appear on a systematic fashion (like one time
> out of 5 to 10 builds), which typically leads one to think it's a
> parallel build problem.
> But we're building Ruby with $(MAKE1), which means we're not doing
> parallel build, so the problem should appear every time, no? Do you
> have an explanation as to why the problem only appears from time to
I think it maybe a timestamp race condition, see  for investigation with
source file links, but basically the problem is the creation of a
temporarily verconf.h file in the configuration step and a timestamp
dependency for rebuild (with different content) of verconf.h for the
loadpath.o -> verconf.h -> RBCONFIG/.rbconfig.time (build by tool/mkconfig.rb
which, according to he failing build.log, is not detected by the make command
(no log for verconf.h creation)...
Maybe its related to a fast build machine and/or timestamp resolution of the
filesystem and/or timestamp resolution of the make command?
But even some 'native' ruby user/developer seem to come across this problem with
some funny 'resolutions' for the problem, e.g changing quoting of variables
(see / and ).
But did not investigate further as I can not reproduce the problem locally
and could not figure out the original intent of a temp verconf.h version
and/or the timestamp dance for rebuilding another version...
But I am convinced that deleting the temp verconf.h will trigger a correct
rebuild of a valid version of verconf.h for the buildroot case....
> Thomas Petazzoni, CTO, Free Electrons
> Embedded Linux, Kernel and Android engineering
More information about the buildroot