[Buildroot] [PATCH v5 00/19] Reproducible builds

[Arnout Vandecappelle <arnout@mind.be>]

On 21-02-17 09:17, J?r?me Pouiller wrote:
> Hello, 
> 
> On Tuesday 20 December 2016 14:46:17 CET J?r?me Pouiller wrote:
> [...]
>> Patches 11 to 19 are nearly a series in the series. Until now, most of binaries
>> installed by libtool was configured with RPATH pointingto their build
>> directory. Indeed, libtool add this path during compilation in order to be able
>> to execute them directly from build directory. This path should normally
>> removed during install, but Buildroot disable this behavior (patch 15). Simply
>> re-enabling this behavior does not work. Indeed, during relink, libtool try to
>> use .la that are not yet patched and fail to find libraries. On another side,
>> libtool support usage of a sysroot since v1.5. To enable this support, we have
>> to keep original values from .la file (patch 12 and 13) and inform libtool we
>> are using a sysroot (patch 11).
>>
>> Patch 14 fix a small incompatibility with unsafe path detection.
>>
>> Since libtool is now correctly used, it is not more necessary to disable
>> install directory sanity check (patch 17).
>>
>> From libtool point of view, sysroot is not reachable from $(TARGET_DIR). So,
>> during installation to $(TARGET_DIR), it add an entry in RPATH that point to
>> $(STAGING_DIR). To fix this problem, we just have to inform libtool that
>> $(STAGING_DIR) is reachable (patch 16).
>>
>> Finally, I also clean up libtool infra from modification that seems useless now
>> (patches 18 and 19).
>>
>> I tested this series using internal toolchain and Linaro toolchain with these
>> packages:
>>
>>     BR2_INIT_SYSTEMD=y       (install public libraries in /usr/lib/systemd)
>>     BR2_PACKAGE_LIBCDAUDIO=y (libtool 1.5)
>>     BR2_PACKAGE_LIBLO=y      (libtool 2.2)
>>     BR2_PACKAGE_MADPLAY=y    (unpatched libtool)
>>     BR2_PACKAGE_ALSA_LIB=y   (optional dependency to Madplay)
>>     BR2_PACKAGE_PYTHON=y
>>     BR2_PACKAGE_PYTHON_PY_PYC=y
>>     BR2_PACKAGE_GNUPG2=y
>>
>> Except patches 12 and 13, I think whole series is bisectable.
> [...]
> 
> As I said above, patches 11 to 19 of this series do a strong clean up
> of libtool infrastructure. I think these patches are important for two
> reasons:
> 
>    1. It is the best way to support reproducible build from different
>       build paths
>    2. Currently BR usage of libtool is not standard. These patches use
>       libtool in the right way. It drop unnecessary RPATH from binaries.
>       It drop most of patches applied to libtool.
> 
> However, this series do very intrusive changes and it is difficult to
> review. Consequently, I think it is necessary to apply them very early
> in a development cycle. So, I suggest to apply them to 'next' now.

 Yes, it's time to apply the libtool patches. I have a few spelling corrections
for the commit messages lined up but nothing more, and I'm waiting for a test
build to finish to give my Ack.

 However, I wonder, wouldn't it be a good idea to change our approach? Instead
of patching the ltmain files, why don't we just overwrite them with our own
host-libtool?

 Hm, host-libtool depends on host-m4, so that adds (on my machine) 50 seconds to
the build whenever an autotools package is included... Possibly not acceptable.
We could still take that approach for the case when AUTORECONF=YES, however. But
then again, that would break the symmetry we have now...

 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:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF