[sword-devel] Sword 1.7.3alpha1

[Greg Hellings]

I've created a sword-1.7.3alpha1.tar.gz and uploaded it to the "normal"
alpha location on the server. Those of you willing and interested, please
test it. I plan to cut it as the final version of 1.7.3 by the end of this
weekend if there's not objections to it. Files are stored in sword-1.7.3/
folder under the tarball and it will play and act just like the final
version of the library.

Please, give me some karma, good or bad, if you try it. I don't want to
release 1.7.3 only to find someone was sitting on a build issue.

--Greg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.crosswire.org/pipermail/sword-devel/attachments/20140423/b21c8184/attachment.html>

[Mark Trompell]

Post by Greg Hellings
I've created a sword-1.7.3alpha1.tar.gz and uploaded it to the "normal"
alpha location on the server. Those of you willing and interested, please
test it. I plan to cut it as the final version of 1.7.3 by the end of this
weekend if there's not objections to it. Files are stored in sword-1.7.3/
folder under the tarball and it will play and act just like the final
version of the library.
Please, give me some karma, good or bad, if you try it. I don't want to
release 1.7.3 only to find someone was sitting on a build issue.

No build issues here (foresightlinux).
Build tool just reports (as always):
+ SharedLibrary: /usr/lib64/libsword.so.1.7.3
+ CheckSonames: /usr/lib64/libsword.so.1.7.3 has soname
libsword.so.1.7.3; best practice is that the filename that matches the
soname is a symlink: soname -> soname.minorversion
But nothing to change for a branch release. But maybe something to
consider for sword 1.8?
Especially if abi is compatible with the previous release, the soname
doesn't need to change.
Not sure if this is only with cmake, but I always have to do:
chrpath -d build/bindings/swig/perl/blib/arch/auto/Sword/Sword.so
because our buildtool aborts with:
"CheckDestDir: file /usr/lib/perl5/site_perl/5.8.8/auto/Sword/Sword.so
has illegal RPATH /tmp/rmake/builds/sword/sword-1.7.3/build"
otherwise
Anyway.
I used cmake to build it.
Xiphos 3.1.6 builds fine on top of that.
Only building on our buildcluster. No real tests.

Post by Greg Hellings
--Greg

Mark

[Greg Hellings]

Mark,

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.

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.

--Greg

Post by Mark Trompell

Post by Greg Hellings
I've created a sword-1.7.3alpha1.tar.gz and uploaded it to the "normal"
alpha location on the server. Those of you willing and interested, please
test it. I plan to cut it as the final version of 1.7.3 by the end of

this

Post by Greg Hellings
weekend if there's not objections to it. Files are stored in sword-1.7.3/
folder under the tarball and it will play and act just like the final
version of the library.
Please, give me some karma, good or bad, if you try it. I don't want to
release 1.7.3 only to find someone was sitting on a build issue.

No build issues here (foresightlinux).
+ SharedLibrary: /usr/lib64/libsword.so.1.7.3
+ CheckSonames: /usr/lib64/libsword.so.1.7.3 has soname
libsword.so.1.7.3; best practice is that the filename that matches the
soname is a symlink: soname -> soname.minorversion
But nothing to change for a branch release. But maybe something to
consider for sword 1.8?
Especially if abi is compatible with the previous release, the soname
doesn't need to change.
chrpath -d build/bindings/swig/perl/blib/arch/auto/Sword/Sword.so
"CheckDestDir: file /usr/lib/perl5/site_perl/5.8.8/auto/Sword/Sword.so
has illegal RPATH /tmp/rmake/builds/sword/sword-1.7.3/build"
otherwise
Anyway.
I used cmake to build it.
Xiphos 3.1.6 builds fine on top of that.
Only building on our buildcluster. No real tests.

Post by Greg Hellings
--Greg

Mark
--
Mark Trompell
Foresight Linux Xfce Edition
Cause your desktop should be freaking cool
(and Xfce)
_______________________________________________
sword-devel mailing list: sword-devel at crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.crosswire.org/pipermail/sword-devel/attachments/20140424/95f54775/attachment.html>