Bug 432468 - 3.6.1-1 doesn't work completely
3.6.1-1 doesn't work completely
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: lftp (Show other bugs)
rawhide
All Linux
high Severity medium
: ---
: ---
Assigned To: Martin Nagy
Fedora Extras Quality Assurance
: Reopened
: 432554 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-02-12 01:23 EST by Mamoru TASAKA
Modified: 2016-07-26 19:46 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-03-03 08:46:08 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
move the linked shared objects to %_libdir (2.55 KB, patch)
2008-02-25 06:11 EST, Patrice Dumas
no flags Details | Diff
lftp.spec to set rpath correctly (12.01 KB, text/plain)
2008-02-25 10:57 EST, Mamoru TASAKA
no flags Details
proposal spec file version 2 (12.04 KB, text/plain)
2008-02-27 12:41 EST, Mamoru TASAKA
no flags Details

  None (edit)
Description Mamoru TASAKA 2008-02-12 01:23:34 EST
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.
Comment 1 Martin Nagy 2008-02-12 05:15:00 EST
My mistake, sorry. Fixed in lftp-3.6.1-2.fc9
Thank you for reporting this.
Comment 2 Martin Nagy 2008-02-12 15:26:46 EST
*** Bug 432554 has been marked as a duplicate of this bug. ***
Comment 3 Bruno Wolff III 2008-02-12 15:35:59 EST
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.
Comment 4 Martin Nagy 2008-02-12 15:45:10 EST
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.
Comment 5 Patrice Dumas 2008-02-23 17:36:47 EST
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.
Comment 6 Patrice Dumas 2008-02-23 18:02:40 EST
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.
Comment 7 Patrice Dumas 2008-02-23 18:08:07 EST
If it is agreed I can do the patch for the spec file.
Comment 8 Martin Nagy 2008-02-25 04:21:03 EST
Patrice, I certainly wouldn't mind if you'd do a patch of spec file and I would
include it of course.
Comment 9 Patrice Dumas 2008-02-25 06:11:43 EST
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.
Comment 10 Patrice Dumas 2008-02-25 06:12:52 EST
I will certainly contact upstream to fix this more cleanly by
week end, unless you do it first.
Comment 11 Mamoru TASAKA 2008-02-25 07:18:51 EST
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.
Comment 12 Mamoru TASAKA 2008-02-25 07:25:20 EST
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 
Comment 13 Patrice Dumas 2008-02-25 08:32:58 EST
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. 
Comment 14 Mamoru TASAKA 2008-02-25 10:57:09 EST
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.
Comment 15 Martin Nagy 2008-02-27 11:14:50 EST
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.
Comment 16 Mamoru TASAKA 2008-02-27 12:41:22 EST
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
Comment 17 Patrice Dumas 2008-03-02 19:42:42 EST
Your solution seems right, but (maybe it is just me) also adds
a bit of complexity.
Comment 18 Martin Nagy 2008-03-03 08:46:08 EST
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.

Note You need to log in before you can comment on or make changes to this bug.