[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Using libtool -release versus -version-info breaks packages (ITS#3035)

Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

* Kurt D. Zeilenga (Kurt@OpenLDAP.org) wrote:
> I expect people to be able to make such moves.  An application designed
> for 2.0 should compile just fine with 2.2.

Is this true between 1.x, 2.x and 3.x?

> Funny... I actually got the idea from the Debian Library Packaging Guide.=

Yeah, the much-changed-never-right-not-official 'Debian Library
Packaging Guide'.  I've spoken with the author a number of times about
the problems with his 'Guide', it's gotten better but it's still very
far from being right.  I've been considering starting up essentially
another one which corrects and clarifies some things in it.

> >What I think we probably *would* do is introduce symbol versioning which
> >then followed the SONAME, so something like- LDAP_2_2_SO_0,=3D20
> >LDAP_2_2_SO_1.
> I don't think symbol versioning is supported broadly enough for us
> to use it (in official releases).  But if you want to, have fun.

I wish you'd consider using it where it's available.  On those platforms
you could have a single .so which supported everything for a given
release (2.1, 2.2).  On platforms which didn't support it they'd have to
do whatever it is they've been doing, which probably involves
recompiling when a new ABI comes out, on whichever tree is being used.

I'm considering looking into doing this for the Debian packages which
would make things alot simpler I think.  I expect the ABI changes to be
small and distant enough that we might be able to pull it off reasonably
and it'd probably be nicer than having different source packages and
forcing recompiles of lots of things.


Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

Version: GnuPG v1.2.4 (GNU/Linux)