[Buildroot] [autobuild.buildroot.net] Daily results for 2021-08-17

Arnout Vandecappelle arnout at mind.be
Mon Aug 23 20:55:30 UTC 2021



On 18/08/2021 23:04, Yann E. MORIN wrote:
> Thomas, All,
> 
> On 2021-08-18 22:18 +0200, Thomas Petazzoni spake thusly:
>> On Wed, 18 Aug 2021 13:05:58 +0200
>> "Yann E. MORIN" <yann.morin.1998 at free.fr> wrote:
>>> Not sure the exact reason, but notice that the failures occur at install
>>> time, not build time.
>> I did try with "make host-libcap", which includes the installation
>> step, and I even tried to do a full build of one of the failing
>> defconfigs. The build failed, but much much later, on a completely
>> unrelated package. And manually checking the RPATH of the host-libcap
>> binaries: they are correct.
> 
> Here too.

 Here too. I do notice a big difference however: in my local build, there's no
rebuild of the executables at installation time.

[snip]
> So, the first properly gets our LDFLAGS, the second, not. Pasing
> TARGET_CONFIGURE_OPTS at install time would solve^whide the issue,
> though.
> 
> But OK, what are the dependencies of cap_magic.o?
> 
>     cap_magic.o: execable.h execable.c loader.txt
> 
> execable.h and .c are not generated, so they are terminal dependencies.
> 
> loader.txt is generated. And it is generated twice (still form the same
> build):
> 
>     make[3]: Entering directory '/data/buildroot-autobuilder/instance-0/output-1/build/host-libcap-2.52/libcap'
>     gcc -o empty empty.c
>     objcopy --dump-section .interp=/dev/stdout empty > loader.txt
>     [...]
>     make[3]: Leaving directory '/data/buildroot-autobuilder/instance-0/output-1/build/host-libcap-2.52/libcap'
>     /usr/bin/make libpsx.so
>     make[3]: Entering directory '/data/buildroot-autobuilder/instance-0/output-1/build/host-libcap-2.52/libcap'
>     objcopy --dump-section .interp=/dev/stdout empty > loader.txt
>     [...]

 In my local build, it is *not* generated twice. Note that in (at least one of)
the failing build(s), it is in fact generated 4 times: twice at build time and
twice at install time.

> 
> Wha?
> 
> So, it believes loader.txt is out of date wrt a file named 'empty'
> (which is generated from a trivial C file empty.c)

 Note that 'empty' is not regenerated, only 'loader' is...


> So, becasue loader.txt is re-generated a second time, some files are
> re-built at install time. Which explains why we get an issue.
> 
> But then, why is it out of date, at all? I really got stuck there...

 I have a theory, but it's a bit far out... We basically have this:

gcc -o empty empty.c
objcopy --dump-section .interp=/dev/stdout empty > loader.txt

The timestamp of 'empty' is going to be near the end of the gcc run. The
timestamp of 'loader.txt', on the other hand, is going to be all the way at the
beginning of the shell run. So, if the filesystem doesn't have nanosecond
precision, it's possible that 'empty' and 'loader.txt' have the same timestamp.

 It's not a good theory, though, because make shouldn't consider 'loader.txt'
older than 'empty' if they have exactly the same timestamp.



 Ooh, I just discovered something nasty! Apparently, objcopy updates the
modification time of its input file...

$ touch empty; ls -l --full-time empty loader.txt; make SHARED=yes loader.txt;
ls -l --full-time empty loader.txt
-rwxr-xr-x 1 arnout arnout 24K 2021-08-23 22:53:27.450172624 +0200 empty*
-rw-r--r-- 1 arnout arnout  28 2021-08-23 22:52:57.949935937 +0200 loader.txt
objcopy --dump-section .interp=/dev/stdout empty > loader.txt
-rwxr-xr-x 1 arnout arnout 24K 2021-08-23 22:53:27.563173530 +0200 empty*
-rw-r--r-- 1 arnout arnout  28 2021-08-23 22:53:27.563173530 +0200 loader.txt

I guess this way there is some chance that loader.txt gets a modification time
just before the updated mtime of empty...

So the solution would be to touch loader.txt just after creating it. We could
patch it like that, give it a go in the autobuilders, then send the patch upstream?

 Regards,
 Arnout



> Could it be that this is a parallel build issue? I doubt it, though...
> 
> I'm out of clues now, so I'll let a godd night's sleep try to solve
> this....
> 
> Regards,
> Yann E. MORIN.
> 
>>> Also, notice spurious errors from ldconfig:
>>>
>>>     /sbin/ldconfig
>>>     /sbin/ldconfig.real: Can't create temporary cache file /etc/ld.so.cache~: Permission denied
>>>     make[5]: [Makefile:162: install-shared-psx] Error 1 (ignored)
>>>
>>> (ldconfig is a wrapper around ldconfig.real, specific to debian and.or
>>> ubuntu I guess)
>>
>> Right, but the absence/presence of the RPATH should normally not be
>> affected by this, I believe.
> 
> Nope, nope.
> 
> Regards,
> Yann E. MORIN.
> 


More information about the buildroot mailing list