| Summary: | check-host-rpath script returns false positives when rpath contains symlink | ||
|---|---|---|---|
| Product: | buildroot | Reporter: | Aaron Bamberger <abamberger> |
| Component: | Other | Assignee: | unassigned |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | buildroot |
| Priority: | P5 | ||
| Version: | 2015.11 | ||
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Host: | Target: | ||
| Build: | |||
| Attachments: | Patch for support/scripts/check_host_rpath script | ||
(In reply to Aaron Bamberger from comment #0) > The path that buildroot is checked out under on our build server contains a > symlink (it's checked out under /home, which is actually a symlink to > /share/home). After looking at the RUNPATH of the libraries that are > triggering the error, it appears that something in the build system is > canonicalizing the RUNPATH (it contains /share/home), while the hostdir that > the script is checking against has not been canonicalized (it just contains > /home). Therefore, even though the paths are logically the same, the string > comparison of the paths in the script returns false. Indeed, this is a known issue for which a patch fixing it globally in Buildroot, is pending in patchwork [1]. [1] http://patchwork.ozlabs.org/patch/576593/ Regards, (In reply to Samuel Martin from comment #1) Ah, that explains why I didn't find any relevant existing bugs by searching for rpath/runpath in particular, thanks for pointing me in the right direction. Do I close this bug, or is that someone else's job (I'm not sure of the proper etiquette)? (In reply to Aaron Bamberger from comment #2) This bug can be kept opened until the patch pointed by Samuel actually gets merged. This bug is now fixed thanks to the patches from Samuel that ensure that the output directory is a canonical path. See the following commit: https://git.buildroot.org/buildroot/commit/?id=173135df5b69dfd5ae6fe6cf2de8833c6f74c143 |
Created attachment 6296 [details] Patch for support/scripts/check_host_rpath script A project I am working on recently updated from buildroot 2015.08 to 2015.11.1. After the upgrade, our build started breaking with the error message "ERROR: package <package> installs executables without proper RPATH", which I eventually tracked down to the support/scripts/check-host-rpath script, which appears to be new in 2015.11. Unfortunately, I don't have a reliable set of steps to reproduce, as I was never able to reproduce this issue in a deterministic manner. Different builds would produce the error messages for different packages, and sometimes would complete successfully without the error appearing at all. Regardless, I believe I've been able to determine at least a partial cause for the issue (possibly not the root cause), and have come up with a fix. The path that buildroot is checked out under on our build server contains a symlink (it's checked out under /home, which is actually a symlink to /share/home). After looking at the RUNPATH of the libraries that are triggering the error, it appears that something in the build system is canonicalizing the RUNPATH (it contains /share/home), while the hostdir that the script is checking against has not been canonicalized (it just contains /home). Therefore, even though the paths are logically the same, the string comparison of the paths in the script returns false. I fixed this issue by modifying the check-host-rpath script to use realpath to canonicalize both the R(UN)PATH parsed from the library, and the hostdir used by the script to check against. I have no idea if this is the best way to fix this, as I don't have a very solid understanding of how the R(UN)PATHS are built into the libraries, or if using realpath is portable. The compiler on the build system is gcc 4.7.3 for x86_64, and the build server is running gentoo linux with kernel 3.14.14 I've attached a patch with my changes to the check-host-rpath script. I understand that patches are only accepted via the mailing list, I'm mostly posting it here for informational purposes. I wanted to get some feedback on whether this was a valid solution for this issue (or if it's even going in the right direction) before posting a potential patch to the mailing list