Description of problem: 3.6.1-1.fc9 doesn't work completely. If I set LD_LIBRARY_PATH, it seems to work. [tasaka1@localhost ~]$ rpm -q lftp lftp-3.6.1-1.fc9.i386 [tasaka1@localhost ~]$ LANG=C lftp ftp://ftp.kddilabs.jp/ liblftp-network.so: cannot open shared object file: No such file or directory lftp: ftp - not supported protocol [tasaka1@localhost ~]$ LANG=C lftp http://koji.fedoraproject.org/packages/lftp/ liblftp-network.so: cannot open shared object file: No such file or directory lftp: http - not supported protocol [tasaka1@localhost ~]$ rpm -ql lftp | grep lftp-network /usr/lib/lftp/3.6.1/liblftp-network.so [tasaka1@localhost ~]$ LANG=C LD_LIBRARY_PATH=/usr/lib/lftp/3.6.1/ lftp ftp://ftp.kddilabs.jp/ cd ok, cwd=/ lftp ftp.kddilabs.jp:/> qui [tasaka1@localhost ~]$ Version-Release number of selected component (if applicable): lftp-3.6.1-1.fc9 How reproducible: 100% Steps to Reproduce: 1. See above 2. 3.
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.