Bug 1254317

Summary: wrong SONAME for biblesync library
Product: [Fedora] Fedora EPEL Reporter: Matěj Cepl <mcepl>
Component: biblesyncAssignee: greg.hellings
Status: CLOSED CURRENTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: epel7CC: greg.hellings, i, mcepl, mcepl
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-05-12 19:59:07 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
suggested patch none

Description Matěj Cepl 2015-08-17 17:10:29 UTC 
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 17:25:41 UTC 
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 20:12:48 UTC 
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 15:03:04 UTC 
(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 19:59:07 UTC 
Yes, this seems to be fixed. Thank you.