Uncertain ABI with libags and GSequencer

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

Uncertain ABI with libags and GSequencer

Joël Krähemann-2
Hello everybody

I'm the developer of Advanced Gtk+ Sequencer or for short gsequencer.
Now I would like to provide following libraries in a non-standard
location like /usr/share/gsequencer.

* libags
* libags-thread
* libags-server
* libags-audio
* libags-gui
* libgsequencer

I think that libgtk-2.0 initially did the same in its early years
about 15 years ago. Are there any documents or guidelines to provide
libraries for debian GNU/Linux? And what if I can't guarantee ABI
conformance, yet? What about providing static linked GSequencer since
I use it to debug the application?


To get a brief overview of the API visit:

http://gsequencer.org/api/ags/

http://gsequencer.org
https://tracker.debian.org/pkg/gsequencer

thank you all.

best regards,
Joël Krähemann

Reply | Threaded
Open this post in threaded view
|

Re: Uncertain ABI with libags and GSequencer

James Cowgill
Hi,

On Wed, 2016-04-20 at 22:46 +0200, Joël Krähemann wrote:

> I'm the developer of Advanced Gtk+ Sequencer or for short gsequencer.
> Now I would like to provide following libraries in a non-standard
> location like /usr/share/gsequencer.
>
> * libags
> * libags-thread
> * libags-server
> * libags-audio
> * libags-gui
> * libgsequencer
>
> I think that libgtk-2.0 initially did the same in its early years
> about 15 years ago. Are there any documents or guidelines to provide
> libraries for debian GNU/Linux? And what if I can't guarantee ABI
> conformance, yet?
Firstly, you should use /usr/lib/gsequencer as the proper place to put
private libraries. /usr/share is for arch-independent files only.

As long as they're private, you can do pretty much what you want with
your libraries. Other Debian packages must not use them however.
Breaking the ABI is also not an issue (for Debian at least).

If you ever want to move them into a public directory you would need to
give them a proper SONAME and make sure the ABI isn't broken regularly.

> What about providing static linked GSequencer since I use it to debug
> the application?

Are you talking about fully statically linked (including static libc
etc) or just statically link against your libraries?

Using static libc is not allowed except in special circumstances. If
it's just your private libraries then you are free to do that if you
want. Is it totally nessesary though? Why can't you debug your
application when it isn't statically linked? Is such a package actually
useful to other people?

James

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

Re: Uncertain ABI with libags and GSequencer

Joël Krähemann-2
On Thu, Apr 21, 2016 at 12:54 AM, James Cowgill <[hidden email]> wrote:

> Hi,
>
> On Wed, 2016-04-20 at 22:46 +0200, Joël Krähemann wrote:
>> I'm the developer of Advanced Gtk+ Sequencer or for short gsequencer.
>> Now I would like to provide following libraries in a non-standard
>> location like /usr/share/gsequencer.
>>
>> * libags
>> * libags-thread
>> * libags-server
>> * libags-audio
>> * libags-gui
>> * libgsequencer
>>
>> I think that libgtk-2.0 initially did the same in its early years
>> about 15 years ago. Are there any documents or guidelines to provide
>> libraries for debian GNU/Linux? And what if I can't guarantee ABI
>> conformance, yet?
>
> Firstly, you should use /usr/lib/gsequencer as the proper place to put
> private libraries. /usr/share is for arch-independent files only.
>
> As long as they're private, you can do pretty much what you want with
> your libraries. Other Debian packages must not use them however.
> Breaking the ABI is also not an issue (for Debian at least).
>
> If you ever want to move them into a public directory you would need to
> give them a proper SONAME and make sure the ABI isn't broken regularly.
>
Yes, this is my intention to provide in a public directory once it reaches the
release 1.0. So libags-1.0.so would be a proper SONAME?

>> What about providing static linked GSequencer since I use it to debug
>> the application?
>
> Are you talking about fully statically linked (including static libc
> etc) or just statically link against your libraries?
>
I didn't have set the priority to investigate the issue but this is
related to the
current Makefile.am. I'm using *.la libaries what gdb or valgrind can't handle.

> Using static libc is not allowed except in special circumstances. If
> it's just your private libraries then you are free to do that if you
> want. Is it totally nessesary though? Why can't you debug your
> application when it isn't statically linked? Is such a package actually
> useful to other people?
>
> James

Joël

Reply | Threaded
Open this post in threaded view
|

Re: Uncertain ABI with libags and GSequencer

Paul Wise via nm
On Thu, Apr 21, 2016 at 7:17 PM, Joël Krähemann wrote:

> So libags-1.0.so would be a proper SONAME?

This SONAME encodes "API number 1.0" and "no ABI number".

Ideally you would have the opposite in the SONAME.

You might want to read through the Debian shared library policy:

https://www.debian.org/doc/debian-policy/ch-sharedlibs.html

--
bye,
pabs

https://wiki.debian.org/PaulWise