Bug 432468

My mistake, sorry. Fixed in lftp-3.6.1-2.fc9
Thank you for reporting this.

*** Bug 432554 has been marked as a duplicate of this bug. ***

In case you need it to work before downloading the update, you can create the
file: /etc/ld.so.conf.d/lftp-i386.conf and put the following line in it:
/usr/lib/lftp/3.6.1/
Then run ldconfig .
If the update doesn't overwrite that file, then you can go back and delete it later.

Yes, the update will overwrite the file (although it will be just the same), so
if you fix it this way you don't have to worry about it anymore.

There is some code in lftp to use modules from 
PKGLIBDIR"/"VERSION

It is clearly wrong to add to /etc/ld.so.conf.d/ a directory 
for dlopened files, the code should be fixed instead. It is 
in module.cc.

Ok, I think I have understood the issue. The libraries
liblftp-getdate.so liblftp-network.so liblftp-pty.so are not
dlopened modules, but instead real libraries, and other
modules are linked against those libraries. 

Therefore, these libraries should be compiled and installed like 
other libraries, and have a soname.

Therefore a patch should be sent upstream, and in the mean time
I think that the libraries should just be copied to %{_libdir}
where they belong.

If it is agreed I can do the patch for the spec file.

Patrice, I certainly wouldn't mind if you'd do a patch of spec file and I would
include it of course.

Created attachment 295785 [details]
move the linked shared objects to %_libdir

I also took that opportunity to remove -f to rm and mv
call to have them fail when they are no longer relevant 
have more explicit file names.

You can apply what you want to.

I will certainly contact upstream to fix this more cleanly by
week end, unless you do it first.

Umm..

Does lftp libraries really have to have soname? They are
only used for lftp binaries and actually it seems that upstream
developer wants to hide theire libraries into lftp specific
directory. 

IMO this should be fixed by making lftp binaries
have rpath properly rather than moving libraries into %_libdir
and introduce soname.

And actually:

3.5.14:
[root@localhost 3.5.14]# for f in *so ; do echo -n -e  "$f " ; objdump --headers
--private-headers $f | grep RPATH ; echo ; done
cmd-mirror.so   RPATH       /usr/lib/lftp/3.5.14

cmd-sleep.so   RPATH       /usr/lib/lftp/3.5.14

liblftp-getdate.so 
liblftp-network.so   RPATH       /usr/lib

liblftp-pty.so 
proto-file.so 
proto-fish.so   RPATH       /usr/lib/lftp/3.5.14:/usr/lib

proto-ftp.so   RPATH       /usr/lib/lftp/3.5.14:/usr/lib

proto-http.so   RPATH       /usr/lib/lftp/3.5.14:/usr/lib

proto-sftp.so   RPATH       /usr/lib/lftp/3.5.14:/usr/lib

3.6.1:
[root@localhost 3.6.1]# for f in *so ; do echo -n -e  "$f " ; objdump --headers
--private-headers $f | grep RPATH ; echo ; done
cmd-mirror.so 
cmd-sleep.so 
liblftp-getdate.so 
liblftp-network.so 
liblftp-pty.so 
proto-file.so 
proto-fish.so 
proto-ftp.so 
proto-http.so 
proto-sftp.so 

Indeed, it is a solution but I think having private libs in 
%_libdir, but using -release in libtool call also solve that issue. The 
issue with rpaths, is that it is not easy to have only rpaths for 
/usr/lib/lftp/3.5.14 and avoid the /usr/lib we really don't want to be
here. 

Created attachment 295807 [details]
lftp.spec to set rpath correctly

The attached spec file sets rpath correctly.
http://koji.fedoraproject.org/koji/taskinfo?taskID=467655
(for debugging, I add some redundant macro and commands
 like "%if 1" or /usr/lib/rpm/check-rpaths)

(In reply to comment #13)
> The 
> issue with rpaths, is that it is not easy to have only rpaths for 
> /usr/lib/lftp/3.5.14 and avoid the /usr/lib we really don't want to be
> here. 

There was two problem:
1. From
http://koji.fedoraproject.org/packages/lftp/3.6.3/1.fc9/data/logs/i386/build.log

-----------------------------------------------------------------
   309	checking for openssl library... OPENSSL_LIBS="-lssl -lcrypto"
OPENSSL_LDFLAGS="-L/usr/lib -R/usr/lib" OPENSSL_CPPFLAGS=-I/usr/include
------------------------------------------------------------------
   This "-R /usr/lib" sets unneeded /usr/lib rpath and this is
   actually not needed....
   Removing this rpath introducing can be done by modifying configure
   a bit.

- And libtool created by lftp actually does _not_ rpath any more.
  Using redhat libtool fixed this.

Mamoru: Your patch seems to work out the rpath, but somehow, I also get this:
$ rpmlint lftp
lftp.i686: W: unused-direct-shlib-dependency /usr/lib/liblftp-jobs.so.0.0.0
/lib/libutil.so.1
lftp.i686: W: unused-direct-shlib-dependency /usr/lib/liblftp-jobs.so.0.0.0
/lib/libncurses.so.5
lftp.i686: W: unused-direct-shlib-dependency /usr/lib/liblftp-jobs.so.0.0.0
/lib/libresolv.so.2
+lftp.i686: W: unused-direct-shlib-dependency /usr/lib/liblftp-jobs.so.0.0.0
/usr/lib/libstdc++.so.6
+lftp.i686: W: unused-direct-shlib-dependency /usr/lib/liblftp-jobs.so.0.0.0
/lib/i686/nosegneg/libm.so.6
lftp.i686: W: unused-direct-shlib-dependency /usr/lib/liblftp-tasks.so.0.0.0
/lib/libutil.so.1
lftp.i686: W: unused-direct-shlib-dependency /usr/lib/liblftp-tasks.so.0.0.0
/lib/libncurses.so.5
lftp.i686: W: unused-direct-shlib-dependency /usr/lib/liblftp-tasks.so.0.0.0
/lib/libresolv.so.2
+lftp.i686: W: unused-direct-shlib-dependency /usr/lib/liblftp-tasks.so.0.0.0
/usr/lib/libstdc++.so.6
+lftp.i686: W: unused-direct-shlib-dependency /usr/lib/liblftp-tasks.so.0.0.0
/lib/i686/nosegneg/libm.so.6

The ones marked with a + weren't there before I applied your patch.

Created attachment 296095 [details]
proposal spec file version 2

Well, then this spec file should fix what you saw.

- The reason rpath was not set was that --disable-rpath
  was added to configure option. Removing this option
  removes the necessity of using system libtool.
- And unneeded rpath (/usr/lib, /usr/lib64, etc...) are
  removed.

http://koji.fedoraproject.org/koji/taskinfo?taskID=473062

Your solution seems right, but (maybe it is just me) also adds
a bit of complexity.

New version was built: lftp-3.6.3-2.fc9
With spec file from comment #16, plus I removed the BR for libtool as we are
using our own libtool. Also some whitespace change I noticed and change of /usr
to %{_prefix} in the %configure line. Thank you very much for your efforts.
Closing this now and I hope there are not any other issues.