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 -rpath $(DESTDIR)$(sbindir) 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 ['/var/tmp/proftpd-1.3.0-1.fc6-root/usr/sbin'] ... Version-Release number of selected component (if applicable): 1.3.0-1.fc6 How reproducible: Every time. Steps to Reproduce: 1. Build proftpd with --enable-dso and a buildroot 2. Check rpaths in resulting binary. Actual results: Bogus rpath Expected results: No bogus rpath :-) Additional info: 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.