error: Failed dependencies

[david kerns]

On Tue, Mar 29, 2016 at 2:58 PM, Tim Mooney <Tim.Mooney at ndsu.edu> wrote:

> In regard to: error: Failed dependencies, david kerns said (at 2:44pm
> on...:
>
> Just joined the mail-list and found an (unresolved) existing thread with my
>> exact issue. I'm hoping this get's linked to the existing thread... (last
>> response Tue, Sep 1, 2015)
>>
>> # rpm -i mypackage.x86_64.rpm
>> error: Failed dependencies:
>>    libtestlib.so()(64bit) is needed by mypackage.x86_64.rpm
>>
>> # rpm -qlp --provides mypackage.x86_64.rpm
>> testlib.so()(64bit)
>> /opt/mypackage/lib/testlib.so
>> /opt/mypackage/lib/libtestlib.so
>>
>
> This is just a guess, but it looks like the shared library you're creating
> either doesn't have a SONAME or the SONAME doesn't match the actual file
> name.
>
> You should probably read up on best practices for creating a shared
> library on your platform (Linux, I presume, though you don't provide
> any details about your OS, distribution, version, or RPM version, all of
> which would be useful to include).
>

ah yes, sorry:
CentOS release 6.7 (Final)
RPM version 4.8.0

This may end the conversation ... (but if there's a fix available on CentOS
6.7, ... we'll be there for a while)
I just tried the exact thing on:

CentOS Linux release 7.2.1511 (Core)
RPM version 4.11.3

and the rpm works without issue. Ugh!


> Note: libtestlib.so is a symbolic link to testlib.so
>>
>> If I make a hard link instead of a symbolic link (during the build
>> process), the rpm install works fine
>>
>
> That seems to confirm that it's an issue with the SONAME.  Read up
> on shared libraries on Linux and the SONAME.
>
> thanks ...
I tried adding (one at a time) both SONAME libtestlib.so and testlib.so ...
both fail with the listed SONAME

$ objdump -p
BUILDROOT/mypackage-1.0-0.1.x86_64/tmp/mypackage/lib/libtestlib.so | grep
SONAME
  SONAME               testlib.so
$ rpm -qlp --provides   RPMS/x86_64/mypackage-1.0-0.1.x86_64.rpm
testlib.so()(64bit)
mypackage = 1.0-0.1
mypackage(x86-64) = 1.0-0.1
/tmp/mypackage
/tmp/mypackage/bin
/tmp/mypackage/bin/main
/tmp/mypackage/lib
/tmp/mypackage/lib/libtestlib.so
/tmp/mypackage/lib/testlib.so
/tmp/mypackage/src


$ objdump -p
BUILDROOT/mypackage-1.0-0.1.x86_64/tmp/mypackage/lib/libtestlib.so | grep
SONAME
  SONAME               libtestlib.so
$ rpm -qlp --provides   RPMS/x86_64/mypackage-1.0-0.1.x86_64.rpm
libtestlib.so()(64bit)
mypackage = 1.0-0.1
mypackage(x86-64) = 1.0-0.1
/tmp/mypackage
/tmp/mypackage/bin
/tmp/mypackage/bin/main
/tmp/mypackage/lib
/tmp/mypackage/lib/libtestlib.so
/tmp/mypackage/lib/testlib.so
/tmp/mypackage/src


PS: if this is a package you will eventually distribute to customers,
> it's even more important that you follow more of the Linux conventions
> for shared libraries.
>
> Tim
> --
> Tim Mooney                                             Tim.Mooney at ndsu.edu
> Enterprise Computing & Infrastructure                  701-231-1076
> (Voice)
> Room 242-J6, Quentin Burdick Building                  701-231-8541 (Fax)
> North Dakota State University, Fargo, ND 58105-5164
>
>
Per Jay Hendron's suggestion:
Maybe a silly suggestion, but could you add a "Provides:
libtestlib.so()(64bit)" tag to your spec file and rebuild?

Which ever (or both) one I list as for "Provides:" adds another depends in
the "rpm -qlp" output.
So, it does seem like a bug, but already fixed by 4.11.3


_______________________________________________
> Rpm-list mailing list
> Rpm-list at lists.rpm.org
> http://lists.rpm.org/mailman/listinfo/rpm-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rpm.org/pipermail/rpm-list/attachments/20160329/f3d3a9f5/attachment.html>