| Message ID | 1504192688-56951-1-git-send-email-sam.voss@rockwellcollins.com |
|---|---|
| State | Superseded |
| Headers | show |
| Series | [V2,1/1] package/strongswan: Install libraries to /usr/lib | expand |
Hello, +Wolfgang in Cc. On Thu, 31 Aug 2017 10:18:08 -0500, Sam Voss wrote: > Install strongswan ipsec libraries into /usr/lib instead of > /usr/lib/ipsec in an effort to not need a custom RPATH for this package. > > Signed-off-by: Sam Voss <sam.voss@rockwellcollins.com> However, as said on IRC: I don't think it is normal that we drop the RPATH from a target binary if this RPATH is needed. So there is probably some additional investigation needed here to figure out if our RPATH-sanitization logic is correct. Wolfgang: Sam realized that stronswan was no longer working, because it installs libraries in a non-standard path (/usr/lib/<something>/). The strongswan build system apparently adds the correct RPATH, but our RPATH sanitization step ($(TOPDIR)/support/scripts/fix-rpath target) removes it. Sam tested after dropping the call to $(TOPDIR)/support/scripts/fix-rpath target, and the RPATH was correct, strongswan would work. Aren't we supposed to keep legitimate RPATH from target binaries ? Thanks! Thomas
Thomas, All, On Thu, Aug 31, 2017 at 10:22 AM, Thomas Petazzoni <thomas.petazzoni@free-electrons.com> wrote: > Hello, [..] > However, as said on IRC: I don't think it is normal that we drop the > RPATH from a target binary if this RPATH is needed. So there is > probably some additional investigation needed here to figure out if our > RPATH-sanitization logic is correct. I completely agree, I am still investigating this cleanup and will get some information out as soon as I get a moment. > Wolfgang: Sam realized that stronswan was no longer working, because it > installs libraries in a non-standard path (/usr/lib/<something>/). The > strongswan build system apparently adds the correct RPATH, but our > RPATH sanitization step ($(TOPDIR)/support/scripts/fix-rpath target) > removes it. Sam tested after dropping the call to > $(TOPDIR)/support/scripts/fix-rpath target, and the RPATH was correct, > strongswan would work. > > Aren't we supposed to keep legitimate RPATH from target binaries ? I took out of our conversation that although that is the case, we still would like to put the libraries into /usr/lib to conform with the rest of BR. Is that still correct? Thanks! Sam Voss
Hello, On Thu, 31 Aug 2017 10:18:08 -0500, Sam Voss wrote: > Install strongswan ipsec libraries into /usr/lib instead of > /usr/lib/ipsec in an effort to not need a custom RPATH for this package. > > Signed-off-by: Sam Voss <sam.voss@rockwellcollins.com> I think you said that the RPATH to /usr/lib/ipsec was being stripped from the Strongswan binary, therefore causing a runtime failure. However, I did a test build, and I do see /usr/lib/ipsec kept in the RPATH: 0x0000001d (RUNPATH) Library runpath: [/usr/lib/ipsec] So, even though installing the libraries in /usr/lib is indeed better for consistency, I'd like to understand why you had an issue running the Strongswan program. Best regards, Thomas
Thomas, All, On Sat, Oct 21, 2017 at 2:51 AM, Thomas Petazzoni <thomas.petazzoni@free-electrons.com> wrote: > However, I did a test build, and I do see /usr/lib/ipsec kept in the > RPATH: > > 0x0000001d (RUNPATH) Library runpath: [/usr/lib/ipsec] My tests seem to be showing the same. I'm going to have to see if it is something we injected ourselves causing the issue. > So, even though installing the libraries in /usr/lib is indeed better > for consistency, I'd like to understand why you had an issue running > the Strongswan program. I can fix the commit message if you'd still like the patch, else I'll leave it as is until I get some more explanation on why we had this issue in the first place. Thanks! Sam
Hello, On Tue, 28 Nov 2017 16:55:48 -0600, Sam Voss wrote: > On Sat, Oct 21, 2017 at 2:51 AM, Thomas Petazzoni > <thomas.petazzoni@free-electrons.com> wrote: > > However, I did a test build, and I do see /usr/lib/ipsec kept in the > > RPATH: > > > > 0x0000001d (RUNPATH) Library runpath: [/usr/lib/ipsec] > > My tests seem to be showing the same. I'm going to have to see if it > is something we injected ourselves causing the issue. > > > So, even though installing the libraries in /usr/lib is indeed better > > for consistency, I'd like to understand why you had an issue running > > the Strongswan program. > > I can fix the commit message if you'd still like the patch, else I'll > leave it as is until I get some more explanation on why we had this > issue in the first place. I think the change does make sense (we try to have all libraries in /usr/lib, except dlopen'ed ones). So if you could resend the patch, but with a modified commit message, it would be nice. Thanks! Thomas
diff --git a/package/strongswan/strongswan.mk b/package/strongswan/strongswan.mk index 1070eea..9fccd99 100644 --- a/package/strongswan/strongswan.mk +++ b/package/strongswan/strongswan.mk @@ -36,7 +36,10 @@ STRONGSWAN_CONF_OPTS += \ --enable-scepclient=$(if $(BR2_PACKAGE_STRONGSWAN_SCEP),yes,no) \ --enable-scripts=$(if $(BR2_PACKAGE_STRONGSWAN_SCRIPTS),yes,no) \ --enable-vici=$(if $(BR2_PACKAGE_STRONGSWAN_VICI),yes,no) \ - --enable-swanctl=$(if $(BR2_PACKAGE_STRONGSWAN_VICI),yes,no) + --enable-swanctl=$(if $(BR2_PACKAGE_STRONGSWAN_VICI),yes,no) \ + --with-ipseclibdir=/usr/lib \ + --with-plugindir=/usr/lib/ipsec/plugins \ + --with-imcvdir=/usr/lib/ipsec/imcvs ifeq ($(BR2_TOOLCHAIN_HAS_LIBATOMIC),y) STRONGSWAN_CONF_ENV += LIBS='-latomic'
Install strongswan ipsec libraries into /usr/lib instead of /usr/lib/ipsec in an effort to not need a custom RPATH for this package. Signed-off-by: Sam Voss <sam.voss@rockwellcollins.com> -- v1->v2 Specify plugindir and imcvdir to keep default values to avoid them moving when ipseclibdir changes. --- package/strongswan/strongswan.mk | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)