Red Hat Bugzilla – Bug 190122
--enable-dso results in bogus rpath
Last modified: 2007-11-30 17:11:31 EST
Description of problem:
Using --enable-dso in proftpd's configure script causes the following to be
included in the resulting Makefile:
MAIN_LDFLAGS=-L$(top_srcdir)/lib/libltdl -dlopen self -export-dynamic
This in turn results in a bogus rpath in the built binary:
$ rpmlint proftpd-1.3.0-1.fc6.i386.rpm
E: proftpd binary-or-shlib-defines-rpath /usr/sbin/proftpd
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Build proftpd with --enable-dso and a buildroot
2. Check rpaths in resulting binary.
No bogus rpath :-)
I guess this is potentially a security issue. Is the rpath needed at all in
Linux? I don't know enough about the workings of linkers to say myself.
Indeed, very very ugly. I'm no linking expert either, but I kind of fail to
understand the use -rpath can have in this case anyway.
I've pushed a rebuild with that very wrong rpath removed.
(In reply to comment #1)
> Indeed, very very ugly. I'm no linking expert either, but I kind of fail to
> understand the use -rpath can have in this case anyway.
Perhaps it's related to this configure test?
checking whether a program can dlopen itself... yes
Maybe the rpath is needed for this in some environments?
I doubt it's of any use here... I've removed that bogus rpath and rebuilt the
package. Even if it's needed, having $DESTDIR in it is plain wrong.