Re: devel/boost: what's proper shared library version?
Folks, Could somebody officially and explicitly tell me, how to assign shared library versions for new boost ports? I see following possibilities: 1) Use boost release version as shared library version. This is safe and recommended by boost. 2) Use some other approach. I do not see alternatives, so please give your advice if you are aginst option #1. Please, remember that boost.org does not examine binary compatibility of their libraries, because this is nearly impossible to do for all platforms and compilers. They also easily may break compatibility even when fixing a bug due to heavy use of metaprogramming. Sincerely, Alexander Churanov, maintainer of devel/boost ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: devel/boost: what's proper shared library version?
* Alexander Churanov (alexanderchura...@gmail.com) wrote:
Could somebody officially and explicitly tell me, how to assign shared
library versions for new boost ports?
I see following possibilities:
1) Use boost release version as shared library version.
This is safe and recommended by boost.
Not official, but couple of thoughts, unfortunately I forgot to anser
your previous message regarding .so versioning.
As I understand, we now assume ABI breakage on every boost update,
correct? In this case .so versioning scheme doesn't really matter, the
important thing is to ensure SONAME recorded in .so files has version
component.
Currently,
% objdump -x libboost_regex.so | grep SONAME
SONAME libboost_regex.so
Thus (example boost-dependent port qtiplot):
% ldd /usr/local/bin/qtiplot | grep boost
libboost_date_time.so = /usr/local/lib/libboost_date_time.so
(0x287be000)
If boost is updated, that'll point to NEW libboost_date_time.so, which
may have ABI broken. However, if SONAME contains version, it will be
like that:
% objdump -x libboost_regex.so | grep SONAME
SONAME libboost_regex.so.1.39
% ldd /usr/local/bin/qtiplot | grep boost
libboost_date_time.so.1.39 = /usr/local/lib/libboost_date_time.so.1.39
(0x287be000)
and when boost is upgraded, this will become
% ldd /usr/local/bin/qtiplot | grep boost
libboost_date_time.so.1.39 =
/usr/local/lib/compat/pkg/libboost_date_time.so.1.39 (0x287be000)
Thus, we ensure that the application does not pick up boost libraries of
different version than it was build with.
Aside for that, versioning scheme doesn't really matter.
As I understand, that's .so.1.39 vs .so.139 vs .so.5
The difference is that with former you can't specify version in
LIB_DEPENDS, i.e. LIB_DEPENDS=boost_date_time.139:${PORTSDIR}/devel/boost,
which will make users update boost before building any dependent
ports and theoretically catch cases where some port requires new boost
version and breaks with the old one. However, that'll be catched in a
most ugly way where new boost is built and this fails on installation
because old boost is still installed. Also one will need to update
version in boost-dependent ports along with portrevision bump.
Currently, there are 30 vs 53 ports with unversioned/versioned depend.
--
Dmitry Marakasov . 55B5 0596 FF1E 8D84 5F56 9510 D35A 80DD F9D2 F77D
amd...@amdmi3.ru ..: jabber: amd...@jabber.ruhttp://www.amdmi3.ru
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: devel/boost: what's proper shared library version?
* Dmitry Marakasov (amd...@amdmi3.ru) wrote: A small addendum: As I understand, that's .so.1.39 vs .so.139 vs .so.5 .so.139 may be not futureproof as there were (and may be later) 3-component versions i.e. 1.34.1. Also, given that boost seem to update fairy regularily, many (pretty huge) ports depend on it and there were no ABI breakages during last updates, I'd vote for only bumping soversion if it's known to break ABI (on major releases or post factum if the breakage is reported). This way the .so.5 scheme seems to be most suitable, as soversion does not correllate with boost version. If on some point we discover that every update needs soversion bump, we can always switch to .so.1.39 or whatever, anyway. -- Dmitry Marakasov . 55B5 0596 FF1E 8D84 5F56 9510 D35A 80DD F9D2 F77D amd...@amdmi3.ru ..: jabber: amd...@jabber.ruhttp://www.amdmi3.ru ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: devel/boost: what's proper shared library version?
2009/5/16 Jeremy Messenger me...@cox.net: It's highly unlike they will break the ABI in the minor release. I'm agree, it's unlikely. But it's possible and there is not warranty. We haven't bump boost when minor version was released and no issue. What number or blah, I don't care as long as you do not bump it for no reason when the ABI isn't broke. It's very hard and time consuming to detect whether a particular library from boost breaks the ABI. I have no automated test suite to verify that and there are no resources for creating one. I am for changing version at every release, since this is what's suggested by boost. However, as a maintainer I'll accept any decision of FreeBSD ports team. Thus, can I be officially instructed what to do? I see following options: 1) Change shared objects version on every release. 2) Change shared objects version on every major release and also if an issue was discovered. 3) Decide myself. Sincerely, Alexander Churanov, maintainer of devel/boost ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: devel/boost: what's proper shared library version?
On Thu, 14 May 2009 13:14:26 -0500, Alexander Churanov alexanderchura...@gmail.com wrote: Jeremy, There is no binary compatibility for boost libraries at all. To be precise, they say this may work for some cases, but boost folks are intentionally not examining if such a compatibility exists between releases. Of course, they provide no warranty of any kind. I've just dropped a message to boost and they confirmed that there is no compatibility between releases. So then, my question was not about binary compatibility. I was sure it does not exist. And yes, we need to rebuild all ports that depend on boost each time the libraries are updated. The question is: how correctly assign versions to shared libraries from boost? I suggest using boost release version, because this is most clear and obvious way. It's supported by boost out-of-box. The only concern is whether library names like libboost_date_time.so.1.39.0 are acceptable for FreeBSD. It's highly unlike they will break the ABI in the minor release. We haven't bump boost when minor version was released and no issue. What number or blah, I don't care as long as you do not bump it for no reason when the ABI isn't broke. Cheers, Mezz Alexander Churanov, maintainer of devel/boost -- me...@cox.net - m...@freebsd.org FreeBSD GNOME Team http://www.FreeBSD.org/gnome/ - gn...@freebsd.org ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: devel/boost: what's proper shared library version?
Jeremy, There is no binary compatibility for boost libraries at all. To be precise, they say this may work for some cases, but boost folks are intentionally not examining if such a compatibility exists between releases. Of course, they provide no warranty of any kind. I've just dropped a message to boost and they confirmed that there is no compatibility between releases. So then, my question was not about binary compatibility. I was sure it does not exist. And yes, we need to rebuild all ports that depend on boost each time the libraries are updated. The question is: how correctly assign versions to shared libraries from boost? I suggest using boost release version, because this is most clear and obvious way. It's supported by boost out-of-box. The only concern is whether library names like libboost_date_time.so.1.39.0 are acceptable for FreeBSD. Alexander Churanov, maintainer of devel/boost ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
devel/boost: what's proper shared library version?
Hi folks! I'm currently working on boost-1.39 port. The wiki http://wiki.freebsd.org/BoostPortingProject reflects most recent project status. And there is a question: what is the proper value for shared libraries installed by boost? As I can see from CVS, devel/boost started setting shared library version explicitly since 1.32. It was 2 for 1.32, then 3 for 1.33, then remained 3 till 1.35. When updating to 1.37 I've changed it to 4, just made +1. Now It's not clear what version should be used for 1.39. Boost.org provides no binary compatibility between versions of their libraries. It seems the best solution is to modify shared libraries version on each version update from boost. The choices are: 1) Just increment number further. It would be 5 for 1.39 2) Use what's boost installer provides (currently so.1.39.0) 3) Use own numbering system, linked to version of boost. For example: so.1390 I don't like option (1), because *so version is not related to version of libraries. For the (2) I've heard that on FreeBSD version must be a single number. I've never seen versions like 1390, as suggested in option (3). What approach to follow? Sincerely, Alexander Churanov, maintainer of devel/boost ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: devel/boost: what's proper shared library version?
On Wed, 13 May 2009 11:26:56 -0500, Alexander Churanov alexanderchura...@gmail.com wrote: Hi folks! I'm currently working on boost-1.39 port. The wiki http://wiki.freebsd.org/BoostPortingProject reflects most recent project status. And there is a question: what is the proper value for shared libraries installed by boost? As I can see from CVS, devel/boost started setting shared library version explicitly since 1.32. It was 2 for 1.32, then 3 for 1.33, then remained 3 till 1.35. When updating to 1.37 I've changed it to 4, just made +1. Now It's not clear what version should be used for 1.39. Boost.org provides no binary compatibility between versions of their libraries. It seems the best solution is to modify shared libraries version on each version update from boost. The choices are: 1) Just increment number further. It would be 5 for 1.39 This is a correct choice. But you only need to bump it if newer version break the ABI. If the binary of library is compatibility, then do not bump it. 2) Use what's boost installer provides (currently so.1.39.0) You can try ltverhack (must have USE_AUTOTOOLS=libtool:15 with it) in bsd.gnome.mk, it's what near all GNOME and a some outside ports use to get same .so.N as Linux. Like our glib2/gtk2 has .so.0 just like Linux. If the ltverhack doesn't work then stick with manual. By the way, ltverhack fix libtool bug for FreeBSD to get correct .so.N. 3) Use own numbering system, linked to version of boost. For example: so.1390 No. This is very ugly, because its force all ports to rebuild at the each time when boost update. It's not need to bump if ABI is compatibility. I don't like option (1), because *so version is not related to version of libraries. The library version is unrelated with release version. It's merely an ABI version, so it bumps when ABI break in the next update. For the (2) I've heard that on FreeBSD version must be a single number. I've never seen versions like 1390, as suggested in option (3). What approach to follow? Sincerely, Alexander Churanov, maintainer of devel/boost -- me...@cox.net - m...@freebsd.org FreeBSD GNOME Team http://www.FreeBSD.org/gnome/ - gn...@freebsd.org ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
