* [Buildroot] [V2 1/1] package/strongswan: Install libraries to /usr/lib
@ 2017-08-31 15:18 Sam Voss
2017-08-31 15:22 ` Thomas Petazzoni
2017-10-21 7:51 ` Thomas Petazzoni
0 siblings, 2 replies; 6+ messages in thread
From: Sam Voss @ 2017-08-31 15:18 UTC (permalink / raw)
To: buildroot
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(-)
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'
--
1.9.1
^ permalink raw reply related [flat|nested] 6+ messages in thread
* [Buildroot] [V2 1/1] package/strongswan: Install libraries to /usr/lib
2017-08-31 15:18 [Buildroot] [V2 1/1] package/strongswan: Install libraries to /usr/lib Sam Voss
@ 2017-08-31 15:22 ` Thomas Petazzoni
2017-08-31 15:31 ` Sam Voss
2017-10-21 7:51 ` Thomas Petazzoni
1 sibling, 1 reply; 6+ messages in thread
From: Thomas Petazzoni @ 2017-08-31 15:22 UTC (permalink / raw)
To: buildroot
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 Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Buildroot] [V2 1/1] package/strongswan: Install libraries to /usr/lib
2017-08-31 15:22 ` Thomas Petazzoni
@ 2017-08-31 15:31 ` Sam Voss
0 siblings, 0 replies; 6+ messages in thread
From: Sam Voss @ 2017-08-31 15:31 UTC (permalink / raw)
To: buildroot
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Buildroot] [V2 1/1] package/strongswan: Install libraries to /usr/lib
2017-08-31 15:18 [Buildroot] [V2 1/1] package/strongswan: Install libraries to /usr/lib Sam Voss
2017-08-31 15:22 ` Thomas Petazzoni
@ 2017-10-21 7:51 ` Thomas Petazzoni
2017-11-28 22:55 ` Sam Voss
1 sibling, 1 reply; 6+ messages in thread
From: Thomas Petazzoni @ 2017-10-21 7:51 UTC (permalink / raw)
To: buildroot
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 Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Buildroot] [V2 1/1] package/strongswan: Install libraries to /usr/lib
2017-10-21 7:51 ` Thomas Petazzoni
@ 2017-11-28 22:55 ` Sam Voss
2017-11-29 7:55 ` Thomas Petazzoni
0 siblings, 1 reply; 6+ messages in thread
From: Sam Voss @ 2017-11-28 22:55 UTC (permalink / raw)
To: buildroot
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Buildroot] [V2 1/1] package/strongswan: Install libraries to /usr/lib
2017-11-28 22:55 ` Sam Voss
@ 2017-11-29 7:55 ` Thomas Petazzoni
0 siblings, 0 replies; 6+ messages in thread
From: Thomas Petazzoni @ 2017-11-29 7:55 UTC (permalink / raw)
To: buildroot
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
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2017-11-29 7:55 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-08-31 15:18 [Buildroot] [V2 1/1] package/strongswan: Install libraries to /usr/lib Sam Voss
2017-08-31 15:22 ` Thomas Petazzoni
2017-08-31 15:31 ` Sam Voss
2017-10-21 7:51 ` Thomas Petazzoni
2017-11-28 22:55 ` Sam Voss
2017-11-29 7:55 ` Thomas Petazzoni
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.