[Ipe-discuss] Re: Building Ipe: shared libs without version
Steve M. Robbins
steve at sumost.ca
Mon Dec 7 05:20:49 CET 2009
On Mon, Dec 07, 2009 at 11:20:10AM +0900, Otfried Cheong wrote:
> Steve M. Robbins wrote:
> >Shared libraries must be versioned to avoid breaking library-using
> >code (e.g. an ipelet) when the library changes. See  for a
> >tutorial and more details.
> >Ipe 6.x built libraries with a SONAME of libipe.so.1. Version 7.0.9
> >doesn't use a SONAME at all. What SONAME should we be using, Otfried?
> Ipe 6 used SONAME libipe.so.1 because that is the default in qmake,
> and since nobody every complained, it remained that way.
> I do not guarantee binary compatibility between different releases
> of Ipe, so in principle the SONAME for all libraries should have the
> full release suffix (currently 7.0.9).
> The other question is whether it is necessary to include the release
> number in the libraries' file names.
I believe you need to provide 1 or 2 file names:
1. Mandatory: file named as the soname; i.e. libipe.so.7.0.9
2. Optional: simpler link-time file name; e.g. libipe.so
No others are needed.
> The ipelet example is not valid, as ipelets need to match the
> current Ipe version anyway - they have to be recompiled for every
> new release of Ipe.
I didn't realize that. How is that requirement enforced; e.g. are
there runtime checks?
> On the other hand, it's theoretically possible that there will be
> other software linking to libipe, and then versioning would be
> Another question is whether libipe.so should actually be libipe7.so
> - that would solve issues where people get mixups because Ipe tries
> to link against an old libipe from Ipe 6. Qt does this (the current
> libraries are QtCore4, QtGui4, etc.). On the other hand, it's
> reasonable to have Qt 3 and Qt 4 on the system, while I do not
> really want people to keep having Ipe 6 and Ipe 7 on their systems
> for a long time (there is zero support for Ipe 6).
I believe Qt does this to support simultaneous install of Qt 3 and Qt
4 *development* environments. You can support this if you wish, but
Debian has no such requirement for Ipe.
The Debian requirement concerns not breaking libipe-linked code when
upgrading the libipe *runtime* package. We name the runtime package
after the soname in order that different runtime ABIs are
simultaneously co-installable; e.g. libipe.so.1 in package name
libipe1 and libipe.so.7.0.9 in package name libipe7.0.9. There is
some overhead introduced with each new package name so I'd be grateful
if you could reconsider ABI compatibility across Ipe versions.
However, if you really cannot guarantee ABI compatibility across Ipe
7.x or 7.0.x, we can live with it.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 190 bytes
Desc: Digital signature
Url : http://lists.science.uu.nl/pipermail/ipe-discuss/attachments/20091206/35a95dbe/attachment.bin
More information about the Ipe-discuss