<div dir="ltr">Mark,<div><br></div><div>Thanks for the report. As for the SONAME, we keep that equal to the version by default. Distributions that care to maintain naming practices around binary compatibility can manually track and set the variable LIBSWORD_SOVERSION through CMake (-DLIBSWORD_SOVERSION=17 for CMake, I forget the equivalent in autotools). Debian has traditionally tracked this on its own, maintaining a simple integer count. Last time I checked it was somewhere around 8 or 9 if memory serves correctly. This is because in times past we did not ensure maintenance of ABI within any specific set of release versions.</div>
<div><br></div><div>With the advent of the 1.7 series (possibly 1.6 as well?) Sword has made a pledge to maintain ABI within a patch-series. Thus, you could set the SOVERSION of the library to "1.7" for this series or whatever you'd like to avoid the duplication. I'm unlikely to add support to CMake to install to 1.7.3 with a symlink to 1.7 and similar, but I'm willing to entertain patches that could be introduced to the next release series (1.8) to make this happen.</div>
<div><br></div><div>--Greg<br><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Apr 24, 2014 at 2:23 AM, Mark Trompell <span dir="ltr"><<a href="mailto:mark@foresightlinux.org" target="_blank">mark@foresightlinux.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Thu, Apr 24, 2014 at 5:25 AM, Greg Hellings <<a href="mailto:greg.hellings@gmail.com">greg.hellings@gmail.com</a>> wrote:<br>
> I've created a sword-1.7.3alpha1.tar.gz and uploaded it to the "normal"<br>
> alpha location on the server. Those of you willing and interested, please<br>
> test it. I plan to cut it as the final version of 1.7.3 by the end of this<br>
> weekend if there's not objections to it. Files are stored in sword-1.7.3/<br>
> folder under the tarball and it will play and act just like the final<br>
> version of the library.<br>
><br>
> Please, give me some karma, good or bad, if you try it. I don't want to<br>
> release 1.7.3 only to find someone was sitting on a build issue.<br>
<br>
</div></div>No build issues here (foresightlinux).<br>
Build tool just reports (as always):<br>
+ SharedLibrary: /usr/lib64/libsword.so.1.7.3<br>
+ CheckSonames: /usr/lib64/libsword.so.1.7.3 has soname<br>
libsword.so.1.7.3; best practice is that the filename that matches the<br>
soname is a symlink: soname -> soname.minorversion<br>
But nothing to change for a branch release. But maybe something to<br>
consider for sword 1.8?<br>
Especially if abi is compatible with the previous release, the soname<br>
doesn't need to change.<br>
Not sure if this is only with cmake, but I always have to do:<br>
chrpath -d build/bindings/swig/perl/blib/arch/auto/Sword/Sword.so<br>
because our buildtool aborts with:<br>
"CheckDestDir: file /usr/lib/perl5/site_perl/5.8.8/auto/Sword/Sword.so<br>
has illegal RPATH /tmp/rmake/builds/sword/sword-1.7.3/build"<br>
otherwise<br>
Anyway.<br>
I used cmake to build it.<br>
Xiphos 3.1.6 builds fine on top of that.<br>
Only building on our buildcluster. No real tests.<br>
<br>
> --Greg<br>
<span class="HOEnZb"><font color="#888888"><br>
Mark<br>
<br>
--<br>
Mark Trompell<br>
<br>
Foresight Linux Xfce Edition<br>
Cause your desktop should be freaking cool<br>
(and Xfce)<br>
<br>
_______________________________________________<br>
sword-devel mailing list: <a href="mailto:sword-devel@crosswire.org">sword-devel@crosswire.org</a><br>
<a href="http://www.crosswire.org/mailman/listinfo/sword-devel" target="_blank">http://www.crosswire.org/mailman/listinfo/sword-devel</a><br>
Instructions to unsubscribe/change your settings at above page<br>
</font></span></blockquote></div><br></div></div></div>