Bug 1254317 - wrong SONAME for biblesync library
wrong SONAME for biblesync library
Status: CLOSED CURRENTRELEASE
Product: Fedora EPEL
Classification: Fedora
Component: biblesync (Show other bugs)
epel7
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: greg.hellings
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-08-17 13:10 EDT by Matěj Cepl
Modified: 2016-05-12 15:59 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-05-12 15:59:07 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
suggested patch (1.68 KB, patch)
2015-08-17 13:25 EDT, Matěj Cepl
no flags Details | Diff

  None (edit)
Description Matěj Cepl 2015-08-17 13:10:29 EDT
Description of problem:

See for more details http://thread.gmane.org/gmane.comp.literature.sword.devel/27404/focus=27496, but more specifically

$ xiphos
xiphos: error while loading shared libraries: libbiblesync.so.1.1.2: cannot open shared object file: No such file or directory
$ ls -l /usr/lib64/libbiblesync.so*
lrwxrwxrwx. 1 root root     19 Aug 16 19:39 \
    /usr/lib64/libbiblesync.so -> libbiblesync.so.1.1
-rwxr-xr-x. 1 root root 107448 Aug 13 18:22 \
    /usr/lib64/libbiblesync.so.1.1
$ objdump -x /usr/lib64/libbiblesync.so.1.1 |grep SONAME
  SONAME               libbiblesync.so.1.1
$ rpm -ql biblesync
/usr/lib64/libbiblesync.so.1.1
/usr/share/doc/biblesync-1.1.2
/usr/share/doc/biblesync-1.1.2/LICENSE
$ rpm -q biblesync
biblesync-1.1.2-3.el7.x86_64
$ rpm -V biblesync
$ 

Shouldn’t that library be /usr/lib64/libbiblesync.so.1.1.2 ?
Comment 1 Matěj Cepl 2015-08-17 13:25:41 EDT
Created attachment 1064018 [details]
suggested patch

This patch seems to fix the issue for EPEL7.

Just a side question: why do we build -gtk2 package at all? We do know for sure, that our users have gtk3 installed (everywhere except of RHEL-6), so why we should build it at all (except of EPEL-6)?
Comment 2 greg.hellings 2016-02-08 15:12:48 EST
This problem doesn't seem present anymore. Matej, can you confirm that it's still an issue?

# ldd /usr/bin/xiphos-gtk2  | grep sync
	libbiblesync.so.1.1 => /lib64/libbiblesync.so.1.1 (0x00007f5f22467000)
	libxcb-sync.so.1 => /lib64/libxcb-sync.so.1 (0x00007f5f16df2000)
# ldd /usr/bin/xiphos-gtk3  | grep sync
	libbiblesync.so.1.1 => /lib64/libbiblesync.so.1.1 (0x00007ff2292e9000)
	libxcb-sync.so.1 => /lib64/libxcb-sync.so.1 (0x00007ff21d34f000)

As for building GTK-2, upstream does not fully support GTK-3 and still recommends building against 2 only. Thus I have provided options to support both while they continue working out issues with their GTK3 support.
Comment 3 greg.hellings 2016-05-12 11:03:04 EDT
(In reply to greg.hellings from comment #2)
> This problem doesn't seem present anymore. Matej, can you confirm that it's
> still an issue?
> 
> # ldd /usr/bin/xiphos-gtk2  | grep sync
> 	libbiblesync.so.1.1 => /lib64/libbiblesync.so.1.1 (0x00007f5f22467000)
> 	libxcb-sync.so.1 => /lib64/libxcb-sync.so.1 (0x00007f5f16df2000)
> # ldd /usr/bin/xiphos-gtk3  | grep sync
> 	libbiblesync.so.1.1 => /lib64/libbiblesync.so.1.1 (0x00007ff2292e9000)
> 	libxcb-sync.so.1 => /lib64/libxcb-sync.so.1 (0x00007ff21d34f000)
> 
> As for building GTK-2, upstream does not fully support GTK-3 and still
> recommends building against 2 only. Thus I have provided options to support
> both while they continue working out issues with their GTK3 support.

Matej,

As noted, can you confirm if this is still an issue? The SO version should be 1.1, as upstream aims to keep binary compatibility within minor release streams. Thus, all 1.1.x versions should be ABI and API compatible.

It looks like newer versions of Xiphos have picked up the proper versioning in their builds.
Comment 4 Matěj Cepl 2016-05-12 15:59:07 EDT
Yes, this seems to be fixed. Thank you.

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