Opened 5 years ago

Closed 5 years ago

#3741 closed defect (worksforme)

installed binaries do not contain RPATH for libs

Reported by: wlodekwencel Owned by: marcin
Priority: very high Milestone: Kea0.9.1
Component: build system Version: git
Keywords: Cc:
CVSS Scoring: Parent Tickets:
Sensitive: no Defect Severity: N/A
Sub-Project: DHCP Feature Depending on Ticket:
Estimated Difficulty: 0 Add Hours to Ticket: 0
Total Hours: 0 Internal?: no

Description

after configure without --prefix option installed binaries do not contain RPATH value it resolve with error during starting servers.

sudo  /usr/local/sbin/keactrl start
INFO/keactrl: Starting kea-dhcp4 -c /usr/local/etc/kea/kea.conf
/usr/local/sbin/kea-dhcp4: error while loading shared libraries: libkea-dhcp++.so.2: cannot open shared object file: No such file or directory
INFO/keactrl: Starting kea-dhcp6 -c /usr/local/etc/kea/kea.conf
/usr/local/sbin/kea-dhcp6: error while loading shared libraries: libkea-asiolink.so.0: cannot open shared object file: No such file or directory

libs needed:

Dynamic Section:
  NEEDED               libkea-dhcp++.so.2
  NEEDED               libkea-dhcp_ddns.so.0
  NEEDED               libkea-util.so.0
  NEEDED               libkea-dhcpsrv.so.3
  NEEDED               libkea-exceptions.so.0
  NEEDED               libkea-asiolink.so.0
  NEEDED               libkea-log.so.1
  NEEDED               libkea-cfgclient.so.0
  NEEDED               libkea-cc.so.0
  NEEDED               libkea-hooks.so.0
  NEEDED               libstdc++.so.6
  NEEDED               libgcc_s.so.1
  NEEDED               libc.so.6

command:

objdump -x /usr/local/sbin/kea-dhcp6 | grep RPATH

show that kea-dhcp6 do not contain RPATH and suppose to show RPATH /usr/lib:

objdump -x /usr/local/sbin/kea-dhcp6 | grep RPATH
  RPATH                /usr/lib

with --prefix switch used RPATH is included properly:

objdump -x /home/test/kea_clean_install/sbin/kea-dhcp6 | grep RPATH
  RPATH                /home/test/kea_clean_install/lib

reproduced on Ubuntu 14.04 64b and Debian 7.8 64b.

Subtickets

Change History (9)

comment:1 Changed 5 years ago by hschempf

  • Milestone changed from Kea-proposed to Kea0.9.1
  • Priority changed from medium to very high

comment:2 Changed 5 years ago by wlodekwencel

could not reproduce on FreeBSD 10

comment:3 Changed 5 years ago by marcin

  • Owner set to marcin
  • Status changed from new to accepted

comment:4 Changed 5 years ago by marcin

I was able to reproduce the problem on the Debian7 machine.

comment:5 follow-up: Changed 5 years ago by marcin

There seem to have been a lot of discussions in the past between libtool and Debian maintainers whether or not the rpath should be used: some articles I found are:

I made some investigation on how Kea is installed in that respect and this is what I found:

  • If --prefix is not specified when running the Kea's configure script Kea will be installed in the default location of /usr/local. In that case the libtool doesn't include the rpath to /usr/local/lib where the Kea libs are stored.
  • If --prefix is specified and points to a location in /usr/ (including /usr/local) the rpath is not included as previously. At the same time the installation step fails if the prefix doesn't point to /usr/local.
  • If the --prefix is specified and points to a location outside of /usr, e.g. home dir, the libtool includes the rpath at the link time.

I observe this behavior on Debian, but not on Fedora for example. I don't know for sure but it seems like the libtool does this specific thing for Debian which may indicate that libtool has a "special" code for Debian.

If this is the libtool's intent to not set the rpath on Debian, I don't want to break it by forcing the use of rpath by the use of LDFLAGS and whatnot. At this point I am not even certain I'd be able to do it. Probably. Instead I verified that it is possible to run Kea installed in the default location by using the LD_LIBRARY_PATH:

export LD_LIBRARY_PATH="${LD_LIBRARY_PATH}:/usr/local/lib"

I wonder if this is acceptable to just document that Debian based systems should use the LD_LIBRARY_PATH to point to the location of the Kea libraries.

comment:6 Changed 5 years ago by fdupont

I suggest to follow what security packages do as it can be critical. So look at OpenSSL, Botan, gunnels, etc. IMHO rpath is just an added value for KEA (vs. a vulnerability source)...

comment:7 in reply to: ↑ 5 Changed 5 years ago by jreed

Yes, some distros or operating systems have custom libtool.

I made some investigation on how Kea is installed in that respect and this is what I found:

  • If --prefix is not specified when running the Kea's configure script Kea will be installed in the default location of /usr/local. In that case the libtool doesn't include the rpath to /usr/local/lib where the Kea libs are stored.

It is fine. Does this work? If it doesn't work, I assume the packager or installer will run ldconfig to make sure the linker cache is updated so it sees the new installed libraries.

  • If --prefix is specified and points to a location in /usr/ (including /usr/local) the rpath is not included as previously. At the same time the installation step fails if the prefix doesn't point to /usr/local.

What is the error for the installation step failure?
As above if the installed software doesn't find libraries, then the packager or installer will run ldconfig to make sure the linker cache is updated so it sees the new installed libraries.

  • If the --prefix is specified and points to a location outside of /usr, e.g. home dir, the libtool includes the rpath at the link time.

I assume in that scenario it already works.

We should not use LD_LIBRARY_PATH as a requirement.

We may want to get rid of any logic we include that sets or disables setting it and just let the operating systems own provide tool do its preferred way. (Note this is probably why Red Hat needed our disable rpath switch to override our forced choice.)

comment:8 Changed 5 years ago by marcin

ldconfig works fine and actually our user guide says that it may need to be run after "make install" at times. I think we can just close the ticket.

comment:9 Changed 5 years ago by marcin

  • Resolution set to worksforme
  • Status changed from accepted to closed

I didn't hear/read any objection to closing this ticket. Since the ldconfig works well, and the use of ldconfig is documented in Kea guide I treat this as "worksforme".

Note: See TracTickets for help on using tickets.