Reproducible builds
Get series with b4
b4 am 12851589.XERjbWNCZC@sagittaeVersions newest first · linked by author and title
- v5 Latest posting 2/20 of 19 patches 0 repliesNew
- v5 posting 1/219 patches 0 repliesSuperseded
- v418 patches 0 repliesSuperseded
Earlier versions · 4
| Version | Posted | Patches | Replies | Status |
|---|---|---|---|---|
| v3 posting 2/2 | 0 of 18 patches | 0 replies | Superseded | |
| v3 posting 1/2 | 18 patches | 0 replies | Superseded | |
| v2 | 15 patches | 0 replies | Superseded | |
| v1 | 0 of 15 patches | 0 replies | Superseded |
Patches in v5 posting 2/2 No applies recorded yet
None of the 19 patches the cover letter announces are in this archive.
Reviews trailers per patch
No Reviewed-by, Acked-by or Tested-by trailers for v5 yet.
Cover letter [Buildroot] [PATCH v5 00/19] Reproducible builds
Hello,
On Tuesday 20 December 2016 14:46:17 CET J?r?me Pouiller wrote:
[...]
Quoted 36 lines
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
Quoted 1 line
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.
Signature · 3 lines
J?r?me Pouiller, Sysmic Embedded Linux specialist http://www.sysmic.fr