[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [luabind] Naming library with proper SONAME

On Tue, Mar 10, 2009 at 06:30:19PM -0400, Roberto C. Sánchez wrote:
> [My apologies in advance for the cross-posting.]
> On Tue, Mar 10, 2009 at 10:42:36AM +0100, Daniel Wallin wrote:
> > Roberto C. Sánchez wrote:
> > >>
> > > So, I've been trying to build the Debian package with the latest from
> > > the 0.8 branch on github.  It seems like the SONAME thing is not
> > > completely resolved.  I am seeing this after building:
> > > 
> > > roberto@miami:~/src/luabind-upstream$ objdump -p ./bin/gcc-4.3.2/debug/libluabindd.so.0.8.0 |grep SONAME
> > >   SONAME      libluabindd.so.0.8.0
> > 
> > Yes, that's the expected result, isn't it? The reasoning was that it's
> > too difficult to have ABI-compatibility, so we just use the complete
> > version number as the SONAME. "bjam install" will create the unversioned
> > symlink.
> > 
> I am curious as to what people generally think of how the libluabind
> SONAME will be going forward.  I know that certain packages (like
> libssl) have the complete version in the SONAME, but I can't imagine
> that this is a really good idea.  Is this a showstopper for having
> libluabind in Debian, or just for a stable release?  Is this
> discouraged, but otherwise permissible?

I have done some further digging and found a blog post [0] that explains
the issues with templated C++ code and ABI.  What it boils down to is
that if templates are used in a library, it really cannot have an ABI.
I also found a bug report [1] against gecode that was closed with a
similar explanation.  The solution implemented by the libgecode
maintainer in Debian was to increment the SONAME for each release.

That said, I think that the "best" solution is to have a different
SONAME for each release, based on the use of template code.  Since it is
currently being set as the library's release version, that is probably
the way to go.

Additionally, I guess it is important for me (as the person packaging
the .deb) to know what the planned release frequency is going to be.
The reason is that each SONAME change will result in a new package being
created and in a library transition (should libluabind gain any reverse
dependencies).  Each time that happens, the package will have to pass
NEW processing.



[0] http://julipedia.blogspot.com/2005/10/c-templates-and-abi.html
[1] http://www.gecode.org/bugzilla/show_bug.cgi?id=24

Roberto C. Sánchez

Attachment: signature.asc
Description: Digital signature

Reply to: