Naming library with proper SONAME

classic Classic list List threaded Threaded
25 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Naming library with proper SONAME

Roberto C. Sánchez
Hello,

I've been doing some work on luabind packaging for Debian.
Specifically, as part of packaging the 0.8 upstream release, I have been
trying to get everything working by building with Boost.Build and
Boost.Jam, instead of the patched in autotools-based build system.  One
problem is that the Boost-based build does not properly name the library
nor assign it the correct SONAME.  Please incorporate the attached
patch, which was created with help from one of the Boost upstream
developers on IRC.

Regards,

-Roberto

--
Roberto C. Sánchez
http://people.connexer.com/~roberto
http://www.connexer.com

------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
luabind-user mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/luabind-user

01_correct_soname_for_bjam.diff (1K) Download Attachment
signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Naming library with proper SONAME

Daniel Wallin
Roberto C. Sánchez wrote:

> Hello,
>
> I've been doing some work on luabind packaging for Debian.
> Specifically, as part of packaging the 0.8 upstream release, I have been
> trying to get everything working by building with Boost.Build and
> Boost.Jam, instead of the patched in autotools-based build system.  One
> problem is that the Boost-based build does not properly name the library
> nor assign it the correct SONAME.  Please incorporate the attached
> patch, which was created with help from one of the Boost upstream
> developers on IRC.

Hi Roberto,

One question:

> +rule add-version ( name : type ? : property-set )
> +{
> +    if $(type) = SHARED_LIB &&
> +              ( ! ( [ $(property-set).get <target-os> ] in windows cygwin darwin aix ) &&
> +                  ! ( [ $(property-set).get <toolset> ] in pgi ) )
> +   {
> +      local result = [ virtual-target.add-prefix-and-suffix $(name) : $(type) : $(property-set) ] ;
> +      result = $(result).0 ;

Would it be better to include the complete version number here? Or is
that somehow a problem? I'm thinking:

    result = $(result).$(major).$(minor).$(point) ;

So libluabind.so.0.8.0 for the current release.

--
Daniel Wallin
BoostPro Computing
http://www.boostpro.com


------------------------------------------------------------------------------
Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
software. With Adobe AIR, Ajax developers can use existing skills and code to
build responsive, highly engaging applications that combine the power of local
resources and data with the reach of the web. Download the Adobe AIR SDK and
Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
_______________________________________________
luabind-user mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/luabind-user
Reply | Threaded
Open this post in threaded view
|

Re: Naming library with proper SONAME

Roberto C. Sánchez
On Tue, Feb 03, 2009 at 10:11:53PM +0100, Daniel Wallin wrote:

>
> Hi Roberto,
>
> One question:
>
> > +rule add-version ( name : type ? : property-set )
> > +{
> > +    if $(type) = SHARED_LIB &&
> > +              ( ! ( [ $(property-set).get <target-os> ] in windows cygwin darwin aix ) &&
> > +                  ! ( [ $(property-set).get <toolset> ] in pgi ) )
> > +   {
> > +      local result = [ virtual-target.add-prefix-and-suffix $(name) : $(type) : $(property-set) ] ;
> > +      result = $(result).0 ;
>
> Would it be better to include the complete version number here? Or is
> that somehow a problem? I'm thinking:
>
>     result = $(result).$(major).$(minor).$(point) ;
>
> So libluabind.so.0.8.0 for the current release.
>
Hi Daniel,

The short answer is "no".  Ordinarily, your approach would work.
However, the problem is that Boost.Jam uses the library's name as
its SONAME.  According to the Debian Library Packaging Guide [0]:

  "In most cases, if a package version matches the SONAME, it is a sign
  that there is a problem with the versioning scheme. Scrap it, and bash
  the upstream with the libtool manual. It is usually a good sign that
  either he has not read the manual thoroughly, or he has not understood
  it, or both."

In this case, though, it is not a problem with your competence, but
rather a limitation in the fact that Boost.Jam hard codes the library
build name as the SONAME.  This happens because of the way that it
passes the library name as an option to the linker.  For example,
building on Debian Sid, here is the linker command that is created by
Boost.Jam for the debug build:

  "g++" -L"/usr/lib"   -o "bin/gcc-4.3.3/debug/libluabind.so.0" -Wl,-h
  -Wl,libluabind.so.0 -shared -Wl,--start-group
  "bin/gcc-4.3.3/debug/class.o" "bin/gcc-4.3.3/debug/class_info.o"
  "bin/gcc-4.3.3/debug/class_registry.o"
  "bin/gcc-4.3.3/debug/class_rep.o" "bin/gcc-4.3.3/debug/create_class.o"
  "bin/gcc-4.3.3/debug/error.o"
  "bin/gcc-4.3.3/debug/exception_handler.o"
  "bin/gcc-4.3.3/debug/find_best_match.o"
  "bin/gcc-4.3.3/debug/function.o" "bin/gcc-4.3.3/debug/implicit_cast.o"
  "bin/gcc-4.3.3/debug/link_compatibility.o"
  "bin/gcc-4.3.3/debug/object_rep.o" "bin/gcc-4.3.3/debug/open.o"
  "bin/gcc-4.3.3/debug/overload_rep.o" "bin/gcc-4.3.3/debug/pcall.o"
  "bin/gcc-4.3.3/debug/ref.o" "bin/gcc-4.3.3/debug/scope.o"
  "bin/gcc-4.3.3/debug/stack_content_by_name.o"
  "bin/gcc-4.3.3/debug/weak_ref.o" "bin/gcc-4.3.3/debug/wrapper_base.o"
  -Wl,-Bstatic -Wl,-Bdynamic -llua5.1 -ldl -lm -Wl,--end-group -g -Wl -z
  defs

The sequence '-Wl,-h -Wl,libluabind.so.0' is what tells the linker how
to set the SONAME.

So, if you named the library libluabind.so.0.8.0 in the build by
modifying the patch as you suggest, then Boost.Jam would helpfully make
its SONAME libluabind.so.0.8.0.  Then when you released 0.8.1 and called
it libluabind.so.0.8.1, Boost.Jam would helpfully make its SONAME
libluabind.so.0.8.1.  This will cause headaches for people trying to
package the library (like me) for some Linux distro.

The way that SONAME works, is that it is "bumped" when there is an
ABI-incompatible change to a library.  That is, the changes are
classified like this:

 - ABI-compatible -> existing symbols are not changed, new symbols are
   possibly added, software build against the library DOES NOT need
   recompiled in order to function -> no SONAME change
 - ABI-incompatible/API-compatible -> existing symbols may change,
   symbols may be added or removed, source built against library
   DOES require recompile in order to work -> SONAME gets bumped
 - API-incompatible -> a simple recompile will not be sufficient because
   source must be modified to work with new library -> SONAME gets
   bumped and customarily this is a new major release

If not for the limitation of Boost.Jam, then you might be able to do
something like this

libluabind.so.0.8.0 -> SONAME:libluabind.so.0
libluabind.so.0.8.1 -> SONAME:libluabind.so.0
libluabind.so.0.9.0 -> SONAME:libluabind.so.0
libluabind.so.1.0.0 -> SONAME:libluabind.so.1

That would let you have /usr/lib/libluabind.so.0 as a symlink to
libluabind.so.0.8.0, or libluabind.so.0.8.1 or even libluabind.so.0.9.0,
assuming that those versions keep themselves ABI-compatible with their
predecessors.  I think that is what your question above is driving at.

I personally think that Boost.Jam should support SONAME as a competely
seperate option so that it can be explicitely specified at build time.
However, that is not something that it currently does.  Perhaps a bug
should be filed against it.

Regards,

-Roberto

[0] http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html#sonameapiabi

--
Roberto C. Sánchez
http://people.connexer.com/~roberto
http://www.connexer.com

------------------------------------------------------------------------------
Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
software. With Adobe AIR, Ajax developers can use existing skills and code to
build responsive, highly engaging applications that combine the power of local
resources and data with the reach of the web. Download the Adobe AIR SDK and
Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
_______________________________________________
luabind-user mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/luabind-user

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Naming library with proper SONAME

Rene Rivera-2
Roberto C. Sánchez wrote:

> On Tue, Feb 03, 2009 at 10:11:53PM +0100, Daniel Wallin wrote:
>> Hi Roberto,
>>
>> One question:
>>
>>> +rule add-version ( name : type ? : property-set )
>>> +{
>>> +    if $(type) = SHARED_LIB &&
>>> +              ( ! ( [ $(property-set).get <target-os> ] in windows cygwin darwin aix ) &&
>>> +                  ! ( [ $(property-set).get <toolset> ] in pgi ) )
>>> +   {
>>> +      local result = [ virtual-target.add-prefix-and-suffix $(name) : $(type) : $(property-set) ] ;
>>> +      result = $(result).0 ;
>> Would it be better to include the complete version number here? Or is
>> that somehow a problem? I'm thinking:
>>
>>     result = $(result).$(major).$(minor).$(point) ;
>>
>> So libluabind.so.0.8.0 for the current release.
>>
> Hi Daniel,
>
> The short answer is "no".  Ordinarily, your approach would work.
[...]

> The way that SONAME works, is that it is "bumped" when there is an
> ABI-incompatible change to a library.  That is, the changes are
> classified like this:
>
>  - ABI-compatible -> existing symbols are not changed, new symbols are
>    possibly added, software build against the library DOES NOT need
>    recompiled in order to function -> no SONAME change
>  - ABI-incompatible/API-compatible -> existing symbols may change,
>    symbols may be added or removed, source built against library
>    DOES require recompile in order to work -> SONAME gets bumped
>  - API-incompatible -> a simple recompile will not be sufficient because
>    source must be modified to work with new library -> SONAME gets
>    bumped and customarily this is a new major release

Nice summary.

> If not for the limitation of Boost.Jam, then you might be able to do
> something like this
>
> libluabind.so.0.8.0 -> SONAME:libluabind.so.0
> libluabind.so.0.8.1 -> SONAME:libluabind.so.0
> libluabind.so.0.9.0 -> SONAME:libluabind.so.0
> libluabind.so.1.0.0 -> SONAME:libluabind.so.1
>
> That would let you have /usr/lib/libluabind.so.0 as a symlink to
> libluabind.so.0.8.0, or libluabind.so.0.8.1 or even libluabind.so.0.9.0,
> assuming that those versions keep themselves ABI-compatible with their
> predecessors.  I think that is what your question above is driving at.

The basic problem is that for templated C++ code just about any change
is potentially an API-incompatible and ABI-incompatible occurrence.

> I personally think that Boost.Jam should support SONAME as a competely
> seperate option so that it can be explicitely specified at build time.
> However, that is not something that it currently does.  Perhaps a bug
> should be filed against it.

Yes, please file a bug report. It would be especially helpful if you,
since you have good knowledge of how SONAME should work, provided a
suggestion as to what the support should look like.


--
-- Grafik - Don't Assume Anything
-- Redshift Software, Inc. - http://redshift-software.com
-- rrivera/acm.org (msn) - grafik/redshift-software.com
-- 102708583/icq - grafikrobot/aim,yahoo,skype,efnet,gmail


------------------------------------------------------------------------------
Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
software. With Adobe AIR, Ajax developers can use existing skills and code to
build responsive, highly engaging applications that combine the power of local
resources and data with the reach of the web. Download the Adobe AIR SDK and
Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
_______________________________________________
luabind-user mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/luabind-user
Reply | Threaded
Open this post in threaded view
|

Re: Naming library with proper SONAME

Roberto C. Sánchez
On Mon, Feb 09, 2009 at 09:46:54PM -0600, Rene Rivera wrote:
>
> The basic problem is that for templated C++ code just about any change
> is potentially an API-incompatible and ABI-incompatible occurrence.
>
Hmm.  I am not particularly experienced with templated library code.  I
suppose that one potential strategy would be to make the complete
release version string part of the SONAME.  The problem is that fast
successive releases make this very problematic.

For example, each time a library SONAME changes, the library must have a
transition.  I can certainly see repeated transitions for the same
library annoying many people.

>
> Yes, please file a bug report. It would be especially helpful if you,
> since you have good knowledge of how SONAME should work, provided a
> suggestion as to what the support should look like.
>
OK.  Bug filed: https://svn.boost.org/trac/boost/ticket/2746

If there is anyting else I can do to help out on this.

Regards,

-Roberto

--
Roberto C. Sánchez
http://people.connexer.com/~roberto
http://www.connexer.com

------------------------------------------------------------------------------
Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
software. With Adobe AIR, Ajax developers can use existing skills and code to
build responsive, highly engaging applications that combine the power of local
resources and data with the reach of the web. Download the Adobe AIR SDK and
Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
_______________________________________________
luabind-user mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/luabind-user

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Naming library with proper SONAME

Daniel Wallin
In reply to this post by Rene Rivera-2
Rene Rivera wrote:

> Roberto C. Sánchez wrote:
>> The way that SONAME works, is that it is "bumped" when there is an
>> ABI-incompatible change to a library.  That is, the changes are
>> classified like this:
>>
>>  - ABI-compatible -> existing symbols are not changed, new symbols are
>>    possibly added, software build against the library DOES NOT need
>>    recompiled in order to function -> no SONAME change
>>  - ABI-incompatible/API-compatible -> existing symbols may change,
>>    symbols may be added or removed, source built against library
>>    DOES require recompile in order to work -> SONAME gets bumped
>>  - API-incompatible -> a simple recompile will not be sufficient because
>>    source must be modified to work with new library -> SONAME gets
>>    bumped and customarily this is a new major release
>
> Nice summary.

Yes, thank you Roberto.

>> That would let you have /usr/lib/libluabind.so.0 as a symlink to
>> libluabind.so.0.8.0, or libluabind.so.0.8.1 or even libluabind.so.0.9.0,
>> assuming that those versions keep themselves ABI-compatible with their
>> predecessors.  I think that is what your question above is driving at.
>
> The basic problem is that for templated C++ code just about any change
> is potentially an API-incompatible and ABI-incompatible occurrence.

So given this, would my suggestion of simply using the version as the
suffix be OK? Or is it somehow better to have an sequentially increasing
suffix?

We also need to create a symlink with the unversioned name don't we? Or
we'd end up just building libluabind.so.0.8.0, and users will need to
link explicitly to that. Rene, how would we do that with BB?

--
Daniel Wallin
BoostPro Computing
http://www.boostpro.com

------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
_______________________________________________
luabind-user mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/luabind-user
Reply | Threaded
Open this post in threaded view
|

Re: Naming library with proper SONAME

Rene Rivera-2
Daniel Wallin wrote:
> We also need to create a symlink with the unversioned name don't we? Or
> we'd end up just building libluabind.so.0.8.0, and users will need to
> link explicitly to that. Rene, how would we do that with BB?

There's a symlink tool/target in BBv2 that can help...

===
import symlink ;

symlink luabind.0.8.0.so : luabind ;
===

Or something like that... I'm trying to figure out how to get the latest
luabind code to give you a better answer. Since I lost track of things
with the switch to Git (I don't do git since I'm normally on Windows).


--
-- Grafik - Don't Assume Anything
-- Redshift Software, Inc. - http://redshift-software.com
-- rrivera/acm.org (msn) - grafik/redshift-software.com
-- 102708583/icq - grafikrobot/aim,yahoo,skype,efnet,gmail

------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
_______________________________________________
luabind-user mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/luabind-user
Reply | Threaded
Open this post in threaded view
|

Re: Naming library with proper SONAME

Daniel Wallin
Rene Rivera wrote:

> Daniel Wallin wrote:
>> We also need to create a symlink with the unversioned name don't we? Or
>> we'd end up just building libluabind.so.0.8.0, and users will need to
>> link explicitly to that. Rene, how would we do that with BB?
>
> There's a symlink tool/target in BBv2 that can help...
>
> ===
> import symlink ;
>
> symlink luabind.0.8.0.so : luabind ;
> ===
>
> Or something like that... I'm trying to figure out how to get the latest
> luabind code to give you a better answer. Since I lost track of things
> with the switch to Git (I don't do git since I'm normally on Windows).

There's a snapshot download button here that you can use if you don't
want to mess around with Git:

  http://github.com/luabind/luabind/tree/master

Maybe we could create an "install" rule while we're at it. Actually, it
seems like "package.install" might handle the symlink thing, but I'm not
sure..

--
Daniel Wallin
BoostPro Computing
http://www.boostpro.com

------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
_______________________________________________
luabind-user mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/luabind-user
Reply | Threaded
Open this post in threaded view
|

Re: Naming library with proper SONAME

Roberto C. Sánchez
On Sat, Feb 14, 2009 at 11:12:44PM +0100, Daniel Wallin wrote:
>
> There's a snapshot download button here that you can use if you don't
> want to mess around with Git:
>
>   http://github.com/luabind/luabind/tree/master
>
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

Regards,

-Roberto

--
Roberto C. Sánchez
http://people.connexer.com/~roberto
http://www.connexer.com

------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
_______________________________________________
luabind-user mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/luabind-user

signature.asc (204 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Naming library with proper SONAME

Daniel Wallin
Roberto C. Sánchez wrote:

> On Sat, Feb 14, 2009 at 11:12:44PM +0100, Daniel Wallin wrote:
>> There's a snapshot download button here that you can use if you don't
>> want to mess around with Git:
>>
>>   http://github.com/luabind/luabind/tree/master
>>
> 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 just released 0.8.1, so you probably want to pull again to get the
final release with the proper version number in the Jamfile.

BTW, note that the default build variant is "debug" only, so for
packaging purposes you probably want "bjam release debug" to get both
release and debug binaries.

--
Daniel Wallin
BoostPro Computing
http://www.boostpro.com

------------------------------------------------------------------------------
_______________________________________________
luabind-user mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/luabind-user
Reply | Threaded
Open this post in threaded view
|

Re: Naming library with proper SONAME

Roberto C. Sánchez
[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've looked in the Debian library packaging guide and it does not say
one way or the other.

I'd appreciate any insights and/or comments.

Regards,

-Roberto

--
Roberto C. Sánchez
http://people.connexer.com/~roberto
http://www.connexer.com

------------------------------------------------------------------------------
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
_______________________________________________
luabind-user mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/luabind-user

signature.asc (204 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Naming library with proper SONAME

Pau Garcia i Quiles
On Tue, Mar 10, 2009 at 11:30 PM, Roberto C. Sánchez
<[hidden email]> 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've looked in the Debian library packaging guide and it does not say
> one way or the other.

Read:
http://www.elpauer.org/?p=230

"If your library version is the same as your soname version, you have
not understood a thing of what I said above" :-)

Soversion should be a *single* unsigned int, starting from 0.

Why using the version number as the soversion is a bad, bad idea?
Because bumping soversion means you have broken binary compatibility.
Now, let's imagine this scenario:

luabind version      ABI break?    soversion
------------------------       -----------------    ----------------

0.8.1                       N/A               0
0.8.2                       no                 0
0.9.0                       no                 0
0.9.1                       yes                1
0.10.0                     yes                2
etc

"ABI break?" = "is this version binary compatible with the previous version?"

See? From 0.8.1 to 0.8.2, and from 0.8.2 to 0.9.0 luabind did not
break ABI, so there was no need to bump soversion. If you were using
the luabind version number as the soversion, you would be saying "I'm
breaking ABI with every luabind release", which is not true.

--
Pau Garcia i Quiles
http://www.elpauer.org
(Due to my workload, I may need 10 days to answer)

------------------------------------------------------------------------------
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
_______________________________________________
luabind-user mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/luabind-user
Reply | Threaded
Open this post in threaded view
|

Re: Naming library with proper SONAME

Roberto C. Sánchez
On Wed, Mar 11, 2009 at 12:02:09AM +0100, Pau Garcia i Quiles wrote:

>
> Read:
> http://www.elpauer.org/?p=230
>
> "If your library version is the same as your soname version, you have
> not understood a thing of what I said above" :-)
>
> Soversion should be a *single* unsigned int, starting from 0.
>
> Why using the version number as the soversion is a bad, bad idea?
> Because bumping soversion means you have broken binary compatibility.
> Now, let's imagine this scenario:
>
> luabind version      ABI break?    soversion
> ------------------------       -----------------    ----------------
>
> 0.8.1                       N/A               0
> 0.8.2                       no                 0
> 0.9.0                       no                 0
> 0.9.1                       yes                1
> 0.10.0                     yes                2
> etc
>
> "ABI break?" = "is this version binary compatible with the previous version?"
>
> See? From 0.8.1 to 0.8.2, and from 0.8.2 to 0.9.0 luabind did not
> break ABI, so there was no need to bump soversion. If you were using
> the luabind version number as the soversion, you would be saying "I'm
> breaking ABI with every luabind release", which is not true.
>
I completely understand.  However, what the luabind upstream developers
are proposing is to have the version be the SONAME.  I understand that
it is "wrong."  However, I am simply packaging for Debian. I am simply
trying to guage people's feelings with regard to SONAME issue as it
pertains to the package's suitability to be in Debian.

Regards,

-Roberto
--
Roberto C. Sánchez
http://people.connexer.com/~roberto
http://www.connexer.com

------------------------------------------------------------------------------
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
_______________________________________________
luabind-user mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/luabind-user

signature.asc (204 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Naming library with proper SONAME

Pau Garcia i Quiles
On Wed, Mar 11, 2009 at 12:25 AM, Roberto C. Sánchez
<[hidden email]> wrote:

> On Wed, Mar 11, 2009 at 12:02:09AM +0100, Pau Garcia i Quiles wrote:
>>
>> Read:
>> http://www.elpauer.org/?p=230
>>
>> "If your library version is the same as your soname version, you have
>> not understood a thing of what I said above" :-)
>>
>> Soversion should be a *single* unsigned int, starting from 0.
>>
>> Why using the version number as the soversion is a bad, bad idea?
>> Because bumping soversion means you have broken binary compatibility.
>> Now, let's imagine this scenario:
>>
>> luabind version      ABI break?    soversion
>> ------------------------       -----------------    ----------------
>>
>> 0.8.1                       N/A               0
>> 0.8.2                       no                 0
>> 0.9.0                       no                 0
>> 0.9.1                       yes                1
>> 0.10.0                     yes                2
>> etc
>>
>> "ABI break?" = "is this version binary compatible with the previous version?"
>>
>> See? From 0.8.1 to 0.8.2, and from 0.8.2 to 0.9.0 luabind did not
>> break ABI, so there was no need to bump soversion. If you were using
>> the luabind version number as the soversion, you would be saying "I'm
>> breaking ABI with every luabind release", which is not true.
>>
>
> I completely understand.  However, what the luabind upstream developers
> are proposing is to have the version be the SONAME.  I understand that
> it is "wrong."  However, I am simply packaging for Debian. I am simply
> trying to guage people's feelings with regard to SONAME issue as it
> pertains to the package's suitability to be in Debian.

Ideally upstream (Daniel) should change his mind and use an unsigned
int as the soname, instead of the version.

For a library I package ( http://packages.debian.org/witty) I worked
with upstream. After exchanging a few e-mails and clarifications, they
understood soversioning very well and adopted a proper sonaming
scheme.

--
Pau Garcia i Quiles
http://www.elpauer.org
(Due to my workload, I may need 10 days to answer)

------------------------------------------------------------------------------
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
_______________________________________________
luabind-user mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/luabind-user
Reply | Threaded
Open this post in threaded view
|

Re: Naming library with proper SONAME

Roberto C. Sánchez
On Wed, Mar 11, 2009 at 12:44:20AM +0100, Pau Garcia i Quiles wrote:
>
> Ideally upstream (Daniel) should change his mind and use an unsigned
> int as the soname, instead of the version.
>
> For a library I package ( http://packages.debian.org/witty) I worked
> with upstream. After exchanging a few e-mails and clarifications, they
> understood soversioning very well and adopted a proper sonaming
> scheme.
>
I agree.  However, in an earlier message Daniel said:

  "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 have made an attempt at explaining soversioning.  However, it appears
that I have made it appear too complex.  Perhaps your blog posting will
convinve Daniel to adopt a more reasonable approach.

Regards,

-Roberto

--
Roberto C. Sánchez
http://people.connexer.com/~roberto
http://www.connexer.com

------------------------------------------------------------------------------
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
_______________________________________________
luabind-user mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/luabind-user

signature.asc (204 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Naming library with proper SONAME

Goswin von Brederlow-2
In reply to this post by Roberto C. Sánchez
Roberto C. Sánchez <[hidden email]> writes:

> [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've looked in the Debian library packaging guide and it does not say
> one way or the other.
>
> I'd appreciate any insights and/or comments.
>
> Regards,
>
> -Roberto

The ABI needs to be compatible across all versions with the same
SONAME. If that means every upstream release gets a new SONAME than I
curse upstream for breaking their ABI all the time but the SONAME
would still be right. This should not really be a showstopper but
maintaining this won't be too easy. Every new upstream release will
need a binary package name change, NEW procesing and a library
transition.  You better hope that the API doesn't change as often so
binNMUs can be done.

One would hope that at some point there will be a libluabindd 1.0.0
which would then have a more stable ABI.

MfG
        Goswin

------------------------------------------------------------------------------
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
_______________________________________________
luabind-user mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/luabind-user
Reply | Threaded
Open this post in threaded view
|

Re: Naming library with proper SONAME

Pau Garcia i Quiles
On Wed, Mar 11, 2009 at 9:01 AM, Goswin von Brederlow <[hidden email]> wrote:

> Roberto C. Sánchez <[hidden email]> writes:
>
>> [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've looked in the Debian library packaging guide and it does not say
>> one way or the other.
>>
>> I'd appreciate any insights and/or comments.
>>
>> Regards,
>>
>> -Roberto
>
> The ABI needs to be compatible across all versions with the same
> SONAME. If that means every upstream release gets a new SONAME than I
> curse upstream for breaking their ABI all the time but the SONAME
> would still be right. This should not really be a showstopper but
> maintaining this won't be too easy. Every new upstream release will
> need a binary package name change, NEW procesing and a library
> transition.  You better hope that the API doesn't change as often so
> binNMUs can be done.
>
> One would hope that at some point there will be a libluabindd 1.0.0
> which would then have a more stable ABI.

There is an easy solution for that in Debian: package luabind as a
static library and forget about sonames. That's exactly what I plan to
do with the upcoming witty3 packages, as upstream told me Wt 3.0 will
break ABI very often.

--
Pau Garcia i Quiles
http://www.elpauer.org
(Due to my workload, I may need 10 days to answer)

------------------------------------------------------------------------------
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
_______________________________________________
luabind-user mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/luabind-user
Reply | Threaded
Open this post in threaded view
|

Re: Naming library with proper SONAME

Adeodato Simó-4
In reply to this post by Roberto C. Sánchez
* Roberto C. Sánchez [Tue, 10 Mar 2009 18:30:19 -0400]:

> 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?

It’s certainly not desirable. Do you have an estimation of how many
reverse dependencies libluabind will have? Goswin’s remark about API
compatibility is also an important one.

Cheers,

--
- Are you sure we're good?
- Always.
        -- Rory and Lorelai


------------------------------------------------------------------------------
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
_______________________________________________
luabind-user mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/luabind-user
Reply | Threaded
Open this post in threaded view
|

Re: Naming library with proper SONAME

Roberto C. Sánchez
On Thu, Mar 12, 2009 at 10:18:59PM +0100, Adeodato Simó wrote:

> * Roberto C. Sánchez [Tue, 10 Mar 2009 18:30:19 -0400]:
>
> > 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?
>
> It’s certainly not desirable. Do you have an estimation of how many
> reverse dependencies libluabind will have? Goswin’s remark about API
> compatibility is also an important one.
>
Currently, none of the luabind packages have reverse dependencies
(except for stuff like libluabind-dbg depending on libluabind0).

Regards,

-Roberto

--
Roberto C. Sánchez
http://people.connexer.com/~roberto
http://www.connexer.com

------------------------------------------------------------------------------
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
_______________________________________________
luabind-user mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/luabind-user

signature.asc (204 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Naming library with proper SONAME

Adeodato Simó-4
* Roberto C. Sánchez [Thu, 12 Mar 2009 17:34:20 -0400]:

> > It’s certainly not desirable. Do you have an estimation of how many
> > reverse dependencies libluabind will have? Goswin’s remark about API
> > compatibility is also an important one.

> Currently, none of the luabind packages have reverse dependencies
> (except for stuff like libluabind-dbg depending on libluabind0).

Yes, but I asked about an *estimation* of how many there *will* be.

--
- Are you sure we're good?
- Always.
        -- Rory and Lorelai


------------------------------------------------------------------------------
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
_______________________________________________
luabind-user mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/luabind-user
12