Boost 1.32.0 FreeBSD port ready -- please review patches
Hello Boosters, I am maintaining the FreeBSD port of Boost, and I'd like to ask you to review the changes I had to make in order to get things to work and possibly to merge some of them into your CVS. First some information about Boost on the FreeBSD platform... There are two supported platforms: - FreeBSD 5.3, with gcc 3.4.2, wchar support - FreeBSD 4.10/11 with gcc 2.95.4, no wchar support, build with stlport 4.6.2 and spirit 1.6.2 to overcome compiler insufficiencies. Sprit 1.6.2 is obtained form http://spirit.sf.net, so I wounder if you guys can do anything about it, but it would be great to have tarball that uses UN*X encoded source files (i.e. without CRLF as line separator). If you don't have a FreeBSD installation, you can find the port skeleton (which is basically a set of patches and scripts needed to build a software package) here: http://www.freebsd.org/cgi/cvsweb.cgi/ports/devel/boost/ I will now present all of the patches I made (please don't beat me if I did something ugly or something which might hurt a Boost developer's feelings ;-) The links above a particular patch enable you to download it from FreeBSD's CVS. After that I'll describe briefly the intention of that patch, which is quoted below. One of the intentions of this posting is to check whether I did my changes at the right places, or if the are crude hacks (I suspect some of my changes to the configuration files fall into this category). A total of 8 patches follows, but don't be afraid, most of it is FreeBSD specific, but I wonder if some patches could be merged into Boost's CVS. http://www.freebsd.org/cgi/cvsweb.cgi/~checkout~/ports/devel/boost/files/pat... This patch enables wchar support on FreeBSD 5 and disables it on older versions. Unfortunately, I can't remember, why BOOST_NO_INCLASS_MEMBER_INITIALIZATION was necessary, but it won't hurt, will it? --- boost/config/platform/bsd.hpp.orig Fri Feb 27 14:13:00 2004 +++ boost/config/platform/bsd.hpp Wed Dec 15 16:01:21 2004 @@ -39,9 +39,20 @@ #endif // -// No wide character support in the BSD header files: +// Enable wide character support on FreeBSD 5 and above // -#define BOOST_NO_CWCHAR +#if defined(__FreeBSD__) && (__FreeBSD__ >= 5) +# undef BOOST_NO_CWCHAR +# undef BOOST_NO_SWPRINTF +# undef BOOST_NO_CWCTYPE +# undef BOOST_DEDUCED_TYPENAME +#else +# define BOOST_NO_CWCHAR +# define BOOST_NO_SWPRINTF +# define BOOST_NO_CWCTYPE +#endif + +#define BOOST_NO_INCLASS_MEMBER_INITIALIZATION // // The BSD <ctype.h> has macros only, no functions: http://www.freebsd.org/cgi/cvsweb.cgi/~checkout~/ports/devel/boost/files/patch-tools%3a%3abuild%3a%3av1%3a%3aallyourbase.jam?rev=1.2&content-type=text/plain Starting with Boost v. 1.31.0, I intend to bump the shared library version number with every boost release in order to prevent from problems that are caused by ABI incompatiblities. (This is a requirement of the FreeBSD Ports Collection). --- tools/build/v1/allyourbase.jam.orig Wed Feb 18 14:04:28 2004 +++ tools/build/v1/allyourbase.jam Wed Feb 18 14:02:44 2004 @@ -457,7 +457,7 @@ SPLITPATH ?= ":" ; # dwa -- added missing SPLITPATH STDHDRS ?= /usr/include ; SUFEXE ?= "" ; -SUFDLL ?= .so ; +SUFDLL ?= .so.2 ; SUFLIB ?= .a ; SUFOBJ ?= .o ; PREDLL ?= lib ; http://www.freebsd.org/cgi/cvsweb.cgi/~checkout~/ports/devel/boost/files/patch-tools%3a%3abuild%3a%3av1%3a%3aboost-base.jam?rev=1.1&content-type=text/plain Another requirement of the Ports Collection: Libraries are installed into the same location regardless of built time options. --- tools/build/v1/boost-base.jam.orig Wed Jan 28 23:52:25 2004 +++ tools/build/v1/boost-base.jam Wed Feb 18 14:06:58 2004 @@ -2621,11 +2621,6 @@ local version-tag = [ MATCH "^([^.]+).([^.]+)" : $(version-number[1]) ] ; version-tag = $(version-tag:J="_") ; - tags += $(toolset-tag:J=) ; - tags += $(thread-tag:J=) ; - tags += $(runtime-tag:J=) ; - tags += $(version-tag) ; - if $(tags) { return $(properties) <*><*><tag><prefix>-$(tags:J=-) ; http://www.freebsd.org/cgi/cvsweb.cgi/~checkout~/ports/devel/boost/files/patch-tools%3a%3abuild%3a%3av1%3a%3agcc-stlport-tools.jam?rev=1.1&content-type=text/plain Depending on the FreeBSD version, different compiler and linker options are needed. These option are provided by two environment variables PTHREAD_CFLAGS and PTHREAD_LIBS, but I found no other way of getting the right values into Boost's config files than patching that will placeholder values and using sed(1) to replace those dummies with the actual ones. --- tools/build/v1/gcc-stlport-tools.jam.orig Mon Dec 13 19:13:56 2004 +++ tools/build/v1/gcc-stlport-tools.jam Mon Dec 13 19:14:18 2004 @@ -40,7 +40,7 @@ } case *BSD : { - flags gcc LINKFLAGS <stlport-iostream>on : -pthread ; + flags gcc LINKFLAGS <stlport-iostream>on : %%PTHREAD_LIBS%% ; } case IRIX : { http://www.freebsd.org/cgi/cvsweb.cgi/~checkout~/ports/devel/boost/files/patch-tools%3a%3abuild%3a%3av1%3a%3agcc-tools.jam?rev=1.1&content-type=text/plain The first hunk of the patch is needed because ports in FreeBSD are supposed to obey some global CFLAGS settings (whose optimiziation settings would be overridden by -O0). The second hunk is similar to the last patch. --- tools/build/v1/gcc-tools.jam.orig Thu Jan 22 05:11:52 2004 +++ tools/build/v1/gcc-tools.jam Wed Feb 18 12:57:30 2004 @@ -61,7 +61,7 @@ flags gcc LINKFLAGS <runtime-link>static : -static ; flags gcc CFLAGS <debug-symbols>on : -g ; flags gcc LINKFLAGS <debug-symbols>on : -g ; -flags gcc CFLAGS <optimization>off : -O0 ; +flags gcc CFLAGS <optimization>off : ; flags gcc CFLAGS <optimization>speed : -O3 ; # Other optimizations we might want for GCC @@ -125,8 +125,8 @@ } case *BSD : { - flags gcc CFLAGS <threading>multi : -pthread ; - flags gcc LINKFLAGS <threading>multi : -pthread ; + flags gcc CFLAGS <threading>multi : %%PTHREAD_CFLAGS%% ; + flags gcc LINKFLAGS <threading>multi : %%PTHREAD_LIBS%% ; # there is no -lrt on BSD } case IRIX : http://www.freebsd.org/cgi/cvsweb.cgi/~checkout~/ports/devel/boost/files/FBSD4-patch-boost%3a%3aprogram_options%3a%3adetail%3a%3autf8_codecvt_facet.hpp?rev=1.1&content-type=text/plain This patch is needed for FreeBSD 4 (gcc 2.95) only! I am sure the first hunk could be solved more cleanly by some configuration option, but where? The second hunk is something I am really unsure about, and which I suppose has something to do with FreeBSD's (or gcc 2.95's?) implementation of std::codecvt. Is this necessary on other platforms? --- boost/program_options/detail/utf8_codecvt_facet.hpp.orig Mon Dec 13 18:48:58 2004 +++ boost/program_options/detail/utf8_codecvt_facet.hpp Mon Dec 13 18:49:51 2004 @@ -67,7 +67,7 @@ #elif defined(BOOST_NO_STDC_NAMESPACE) typedef std::mbstate_t mbstate_t; namespace std{ - using ::codecvt; + using std::codecvt; } // namespace std #endif @@ -81,7 +81,7 @@ { public: explicit utf8_codecvt_facet_wchar_t(std::size_t no_locale_manage=0) - : std::codecvt<wchar_t, char, mbstate_t>(no_locale_manage) + : std::codecvt<wchar_t, char, mbstate_t>() // FIXME {} protected: virtual std::codecvt_base::result do_in( http://www.freebsd.org/cgi/cvsweb.cgi/~checkout~/ports/devel/boost/files/FBSD4-patch-libs%3a%3aserialization%3a%3abuild%3a%3aJamfile?rev=1.1&content-type=text/plain FreeBSD 4 only! This disables the build of the wchar version of the serialization library on this platform. I simply couldn't get it to work, AFAIK libc is not ready for wide characters on this platform. --- libs/serialization/build/Jamfile.orig Mon Dec 13 18:36:52 2004 +++ libs/serialization/build/Jamfile Mon Dec 13 18:37:28 2004 @@ -90,12 +90,10 @@ install serialization lib : <lib>boost_serialization - <lib>boost_wserialization ; stage stage/lib : <lib>boost_serialization - <lib>boost_wserialization : <locate>$(BOOST_ROOT) common-stage-tag http://www.freebsd.org/cgi/cvsweb.cgi/~checkout~/ports/devel/boost/files/FBSD5-patch-boost%3a%3apython%3a%3adetail%3a%3aconfig.hpp?rev=1.1&content-type=text/plain FreeBSD 5 only! This works around a bug in FreeBSD's gcc 3.4.2, which has been reported to the maintainer of FreeBSD's system compiler. --- boost/python/detail/config.hpp.orig Tue Dec 14 14:17:42 2004 +++ boost/python/detail/config.hpp Tue Dec 14 14:19:36 2004 @@ -110,7 +110,11 @@ # define BOOST_PYTHON_OFFSETOF(s_name, s_member) \ ((size_t)__INTADDR__(&(((s_name *)0)->s_member))) #else -# define BOOST_PYTHON_OFFSETOF offsetof +// workaround from http://www.freebsd.org/cgi/query-pr.cgi?pr=72307 +#define BOOST_PYTHON_OFFSETOF(TYPE, MEMBER)\ + (__offsetof__ (reinterpret_cast <size_t>\ + (&reinterpret_cast <const volatile char &>\ + (static_cast<TYPE *> (0)->MEMBER)))) #endif #endif // CONFIG_DWA052200_H_
Very helpful. Is there any chance you can upload the test results to the test matrix? Robert Ramey Simon Barner wrote:
Hello Boosters,
This disables the build of the wchar version of the serialization library on this platform. I simply couldn't get it to work, AFAIK libc is not ready for wide characters on this platform.
--- libs/serialization/build/Jamfile.orig Mon Dec 13 18:36:52 2004 +++ libs/serialization/build/Jamfile Mon Dec 13 18:37:28 2004 @@ -90,12 +90,10 @@
install serialization lib : <lib>boost_serialization - <lib>boost_wserialization ;
stage stage/lib : <lib>boost_serialization - <lib>boost_wserialization : <locate>$(BOOST_ROOT) common-stage-tag
The serialization library consists of 2 libraries: serialization and wserialization. wserialization implements those facilities which depend on wide characters. The failure of wserialization to built for lack of wide character support does not inhibit the usage of the library where wide characters are not needed. It turns out that there are number of libraries/compiler combinations which fail to support wide characters or have some problem with them. In these cases the wserialization library will fail to build and the corresponding tests fail to run for lack of a library. So this change should be unnecessary. Furthermore , there are combination which might miight work - for example gcc 3.42(or 2.85) + STLPort so the Jamfile should be left to permit these to be run and tested. To summarize, the jamfile should be set up to permit an attempt to build both libraries. If wserialization fails to build, it indicates that that part of the library cannot be used. However, there's no reason the rest can' t be used and tested. Robert Ramey
Robert Ramey wrote:
Very helpful.
Is there any chance you can upload the test results to the test matrix?
How would I do it? Sorry, I couldn't find it in the Boost documentation. In the meantime, the regression tests for FreeBSD 5.3 have completed (basically, it's nothing but launching run_tests.sh and waiting until it completes, right?). I have uploaded the test results here, but I can submit them at the proper place later. http://home.leo.org/~barner/boost/FreeBSD-5.3/ The tests for FreeBSD 4.11-RC1 are soon to come! [...]
The serialization library consists of 2 libraries: serialization and wserialization. wserialization implements those facilities which depend on wide characters. The failure of wserialization to built for lack of wide character support does not inhibit the usage of the library where wide characters are not needed.
It turns out that there are number of libraries/compiler combinations which fail to support wide characters or have some problem with them. In these cases the wserialization library will fail to build and the corresponding tests fail to run for lack of a library. So this change should be unnecessary. Furthermore , there are combination which might miight work - for example gcc 3.42(or 2.85) + STLPort so the Jamfile should be left to permit these to be run and tested.
To summarize, the jamfile should be set up to permit an attempt to build both libraries. If wserialization fails to build, it indicates that that part of the library cannot be used. However, there's no reason the rest can' t be used and tested.
I think that I introduced the patch because the wserialization library cause the entire build process to terminate, which might or might not be the FreeBSD ports collection's fault. I'll verify this later! Simon
At 06:47 PM 1/6/2005, Simon Barner wrote:
Robert Ramey wrote:
Very helpful.
Is there any chance you can upload the test results to the test matrix?
How would I do it? Sorry, I couldn't find it in the Boost documentation. In the meantime, the regression tests for FreeBSD 5.3 have completed (basically, it's nothing but launching run_tests.sh and waiting until it completes, right?).
I have uploaded the test results here, but I can submit them at the proper place later.
Interesting! Thanks for posting them. I notice that all the "run-fail" tests in Boost.Test are shown as failing. But in looking at the messages, it looks like they really did return a non-zero result, and thus should be marked "pass". Is it possible this operating system treats non-zero return values is some special way? --Beman
Simon Barner writes:
Robert Ramey wrote:
Very helpful.
Is there any chance you can upload the test results to the test matrix?
How would I do it?
See http://www.meta-comm.com/engineering/regression_setup/instructions.html. If you don't want to re-run the whole thing with 'regression.py', you can upload what you've already got by following the instructions in the "Integration with a custom driver script" section.
Sorry, I couldn't find it in the Boost documentation.
It's not your fault, the website needs to be updated on this. -- Aleksey Gurtovoy MetaCommunications Engineering
Aleksey Gurtovoy wrote:
See http://www.meta-comm.com/engineering/regression_setup/instructions.html. If you don't want to re-run the whole thing with 'regression.py', you can upload what you've already got by following the instructions in the "Integration with a custom driver script" section.
Since I accidentally deleted my boost build directory, I had no choice but re-running everything... :-/ Unfortunatelly, the upload setup failed because of our rigid firewall, but I was able to upload the .zip file manually via ftp from a different machine. Simon
Simon Barner wrote:
Hello Boosters,
I am maintaining the FreeBSD port of Boost, and I'd like to ask you to review the changes I had to make in order to get things to work and possibly to merge some of them into your CVS.
First some information about Boost on the FreeBSD platform...
There are two supported platforms:
- FreeBSD 5.3, with gcc 3.4.2, wchar support - FreeBSD 4.10/11 with gcc 2.95.4, no wchar support, build with stlport 4.6.2 and spirit 1.6.2 to overcome compiler insufficiencies.
Sprit 1.6.2 is obtained form http://spirit.sf.net, so I wounder if you guys can do anything about it, but it would be great to have tarball that uses UN*X encoded source files (i.e. without CRLF as line separator).
Hi Simon, tar.gz files have been added: http://sourceforge.net/project/showfiles.php?group_id=28447&release_id=288860 http://sourceforge.net/project/showfiles.php?group_id=28447&release_id=288861 Thanks, Joao! Cheers, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net
http://www.freebsd.org/cgi/cvsweb.cgi/~checkout~/ports/devel/boost/files/pat...
This patch enables wchar support on FreeBSD 5 and disables it on older versions.
Unfortunately, I can't remember, why BOOST_NO_INCLASS_MEMBER_INITIALIZATION was necessary, but it won't hurt, will it?
Probably not, but it still looks like a mistake: gcc-3.3 shouldn't have any issues with this.
--- boost/config/platform/bsd.hpp.orig Fri Feb 27 14:13:00 2004 +++ boost/config/platform/bsd.hpp Wed Dec 15 16:01:21 2004 @@ -39,9 +39,20 @@
Simplified to just: #if !(defined(__FreeBSD__) && (__FreeBSD__ >= 5)) # define BOOST_NO_CWCHAR #endif Tested on FreeBSD 5 via HP testdrive, and looks OK.
Depending on the FreeBSD version, different compiler and linker options are needed. These option are provided by two environment variables PTHREAD_CFLAGS and PTHREAD_LIBS, but I found no other way of getting the right values into Boost's config files than patching that will placeholder values and using sed(1) to replace those dummies with the actual ones.
You can use $(NAME) to refer to an environment variable in bjam, so I assume that this should be:
case *BSD : { - flags gcc LINKFLAGS <stlport-iostream>on : -pthread ; + flags gcc LINKFLAGS <stlport-iostream>on : $(PTHREAD_LIBS) ; }
But maybe a bjam expert can comment.
The first hunk of the patch is needed because ports in FreeBSD are supposed to obey some global CFLAGS settings (whose optimiziation settings would be overridden by -O0).
The second hunk is similar to the last patch.
Again this can refer to the environment variables directly I believe.
This patch is needed for FreeBSD 4 (gcc 2.95) only!
I am sure the first hunk could be solved more cleanly by some configuration option, but where?
The second hunk is something I am really unsure about, and which I suppose has something to do with FreeBSD's (or gcc 2.95's?) implementation of std::codecvt. Is this necessary on other platforms?
It looks like a bug in the program_options code to me, there probably shouldn't be a using ::codecvt; there at all. John.
John Maddock wrote:
http://www.freebsd.org/cgi/cvsweb.cgi/~checkout~/ports/devel/boost/files/pat...
This patch enables wchar support on FreeBSD 5 and disables it on older versions.
Unfortunately, I can't remember, why BOOST_NO_INCLASS_MEMBER_INITIALIZATION was necessary, but it won't hurt, will it?
Probably not, but it still looks like a mistake: gcc-3.3 shouldn't have any issues with this.
--- boost/config/platform/bsd.hpp.orig Fri Feb 27 14:13:00 2004 +++ boost/config/platform/bsd.hpp Wed Dec 15 16:01:21 2004 @@ -39,9 +39,20 @@
Simplified to just:
#if !(defined(__FreeBSD__) && (__FreeBSD__ >= 5)) # define BOOST_NO_CWCHAR
#endif
Tested on FreeBSD 5 via HP testdrive, and looks OK.
Yes, thanks -- this works on my FreeBSD 5 machine, too. When I have verified this on FreeBSD 4, this should be merged into Boost's CVS IMO (unlike the PTHREAD_{CFLAGS,LIBS} patches, which are specific to the ports collection and would prevent building Boost directly from the tarball).
Depending on the FreeBSD version, different compiler and linker options are needed. These option are provided by two environment variables PTHREAD_CFLAGS and PTHREAD_LIBS, but I found no other way of getting the right values into Boost's config files than patching that will placeholder values and using sed(1) to replace those dummies with the actual ones.
You can use $(NAME) to refer to an environment variable in bjam, so I assume that this should be:
Ah, it's $(FOO), and I kept on trying ${FOO}. Now it works, thanks :-) [ snip ] Simon
On Thu, 6 Jan 2005 03:07:38 +0100, Simon Barner <barner@gmx.de> wrote:
Starting with Boost v. 1.31.0, I intend to bump the shared library version number with every boost release in order to prevent from problems that are caused by ABI incompatiblities.
(This is a requirement of the FreeBSD Ports Collection).
--- tools/build/v1/allyourbase.jam.orig Wed Feb 18 14:04:28 2004 +++ tools/build/v1/allyourbase.jam Wed Feb 18 14:02:44 2004 @@ -457,7 +457,7 @@ SPLITPATH ?= ":" ; # dwa -- added missing SPLITPATH STDHDRS ?= /usr/include ; SUFEXE ?= "" ; -SUFDLL ?= .so ; +SUFDLL ?= .so.2 ; SUFLIB ?= .a ; SUFOBJ ?= .o ; PREDLL ?= lib ;
As of Boost 1.32.0, the shared libraries are properly versioned (e.g. they have a proper SONAME attribute set and there is a libboost_XXX.so.1.32.0). Is this change necessary then? There is the unfortunate matter of the version number being encoded in the name TWICE now (e.g. libboost_thread-gcc-mt-1_32.so.1.32.0) which I think is a problem and should be corrected. The versioned shared object should be sufficient without having to encode the Boost version in the part of the name that comes *before* .so. -- Caleb Epstein caleb dot epstein at gmail dot com
Caleb Epstein wrote:
On Thu, 6 Jan 2005 03:07:38 +0100, Simon Barner <barner@gmx.de> wrote:
[...]
-SUFDLL ?= .so ; +SUFDLL ?= .so.2 ;
[...]
As of Boost 1.32.0, the shared libraries are properly versioned (e.g. they have a proper SONAME attribute set and there is a libboost_XXX.so.1.32.0). Is this change necessary then?
Probably still, yes, because as far as I understand FreeBSD's shared library naming scheme is not compatible to your policy: http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/policie... But this patch is very specific to the ports collection (in order to meet the strict rules that were set up to maintain a software build system for 12k+ applications and libraries -- for people who are building Boost directly from source, your naming convention looks good to me. Simon
On Fri, 7 Jan 2005 01:01:07 +0100, Simon Barner <barner@gmx.de> wrote:
Caleb Epstein wrote:
On Thu, 6 Jan 2005 03:07:38 +0100, Simon Barner <barner@gmx.de> wrote:
[...]
-SUFDLL ?= .so ; +SUFDLL ?= .so.2 ;
[...]
As of Boost 1.32.0, the shared libraries are properly versioned (e.g. they have a proper SONAME attribute set and there is a libboost_XXX.so.1.32.0). Is this change necessary then?
Probably still, yes, because as far as I understand FreeBSD's shared librar y naming scheme is not compatible to your policy:
http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/policie...
The first words on that page are: "If you are adding shared library support to a port or other piece of software that *does not have one*" Emphasis mine. Boost has one, so why this patch? -- Caleb Epstein caleb dot epstein at gmail dot com
Caleb Epstein wrote:
On Fri, 7 Jan 2005 01:01:07 +0100, Simon Barner <barner@gmx.de> wrote:
Caleb Epstein wrote:
On Thu, 6 Jan 2005 03:07:38 +0100, Simon Barner <barner@gmx.de> wrote:
[...]
-SUFDLL ?= .so ; +SUFDLL ?= .so.2 ; [...]
As of Boost 1.32.0, the shared libraries are properly versioned (e.g. they have a proper SONAME attribute set and there is a libboost_XXX.so.1.32.0). Is this change necessary then?
Probably still, yes, because as far as I understand FreeBSD's shared library naming scheme is not compatible to your policy:
http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/policie...
The first words on that page are:
"If you are adding shared library support to a port or other piece of software that *does not have one*"
Emphasis mine. Boost has one, so why this patch?
I don't think Simon did it just for fun... I think this part of that handbook is more telling... "That is, if you link with libfoo.so.3.3.3, the linker only records 3.3 in the headers, and will link with anything starting with libfoo.so.3.(anything >= 3).(highest available)." That means that if one links to *.so.1.31.0, the FreeBSD linker will try and link to *.so.1.32.0 if available. Personally I'd say the linker is broken in this respect, as it doesn't follow the historical major.minor.patch where only patch revisions are compatible use. And Boost is certainly not the only library follow this so I can only imagine the havoc this causes all around. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com - 102708583/icq
Rene Rivera <grafik.list@redshift-software.com> writes: | "That is, if you link with libfoo.so.3.3.3, the linker only | records 3.3 in the headers, and will link with anything starting with | libfoo.so.3.(anything >= 3).(highest available)."
| That means that if one links to *.so.1.31.0, the FreeBSD linker will | try and link to *.so.1.32.0 if available. Personally I'd say the | linker is broken in this respect, as it doesn't follow the historical | major.minor.patch where only patch revisions are compatible use. And | Boost is certainly not the only library follow this so I can only | imagine the havoc this causes all around. This is not usually how so-versions are done. The number on a shared lib most often signifies the API/ABI version. That is ortogonal to the version of the lib itself. This warning is given in the documentation for libtool (and I know that boost does not use libtool): *_Never_* try to set the interface numbers so that they correspond to the release number of your package. This is an abuse that only fosters misunderstanding of the purpose of library versions. -- Lgb
Lars Gullik Bjønnes wrote:
The number on a shared lib most often signifies the API/ABI version. That is ortogonal to the version of the lib itself.
Not for Boost. For Boost the version is the API version.
This warning is given in the documentation for libtool (and I know that boost does not use libtool):
*_Never_* try to set the interface numbers so that they correspond to the release number of your package. This is an abuse that only fosters misunderstanding of the purpose of library versions.
So to match the API/ABI version should be set to the minor version of Boost as it's not likely that Boost will ever have anything other than 1 as the major version. Hence the library names would be for 1.32.0: libboost*.so.32.0 And if there was a 1.32.1: libboost*.so.32.1 That would seem to satisfy the FreeBSD and Linux requirements. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com - 102708583/icq
Caleb Epstein wrote:
On Thu, 6 Jan 2005 03:07:38 +0100, Simon Barner <barner@gmx.de> wrote:
Starting with Boost v. 1.31.0, I intend to bump the shared library version number with every boost release in order to prevent from problems that are caused by ABI incompatiblities.
(This is a requirement of the FreeBSD Ports Collection).
As of Boost 1.32.0, the shared libraries are properly versioned (e.g. they have a proper SONAME attribute set and there is a libboost_XXX.so.1.32.0). Is this change necessary then?
There is the unfortunate matter of the version number being encoded in the name TWICE now (e.g. libboost_thread-gcc-mt-1_32.so.1.32.0) which6 I think is a problem and should be corrected. The versioned shared object should be sufficient without having to encode the Boost version in the part of the name that comes *before* .so.
Given my other post about this... Perhaps the 1_32 version tag is not superfluous in this case. And for everyones benefit, that tag is only superfluous on platforms that have soname versions, which is a rather small set for BBv1: gcc on Linux and OpenBSD, Intel Linux, or SunPro. So in the FreeBSD case the 1.32.0 tag is not there AFAIK. ;-) -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com - 102708583/icq
8Simon Barner wrote:
Starting with Boost v. 1.31.0, I intend to bump the shared library version number with every boost release in order to prevent from problems that are caused by ABI incompatiblities.
I think a better approach, given the linker requirements in FreeBSD, is to not remove the 1_32 tag, and set the so postfix to the patch revision. For example: libboost_*-1_32.so.0 Which by the way is what the BBv1 OpenBSD build does.
Another requirement of the Ports Collection: Libraries are installed into the same location regardless of built time options.
OK, but that seems to contradict your patch below. How are you differentiating the possible builds from each other if you are removing the tags that encode those build options?
--- tools/build/v1/boost-base.jam.orig Wed Jan 28 23:52:25 2004 +++ tools/build/v1/boost-base.jam Wed Feb 18 14:06:58 2004 @@ -2621,11 +2621,6 @@ local version-tag = [ MATCH "^([^.]+).([^.]+)" : $(version-number[1]) ] ; version-tag = $(version-tag:J="_") ;
- tags += $(toolset-tag:J=) ; - tags += $(thread-tag:J=) ; - tags += $(runtime-tag:J=) ; - tags += $(version-tag) ; - if $(tags) { return $(properties) <*><*><tag><prefix>-$(tags:J=-) ;
Depending on the FreeBSD version, different compiler and linker options are needed. These option are provided by two environment variables PTHREAD_CFLAGS and PTHREAD_LIBS, but I found no other way of getting the right values into Boost's config files than patching that will placeholder values and using sed(1) to replace those dummies with the actual ones.
As mentioned by others you can use $(PTHREAD_LIBS) to get at the env variables, as all are mirrored by the build system.
--- tools/build/v1/gcc-stlport-tools.jam.orig Mon Dec 13 19:13:56 2004 +++ tools/build/v1/gcc-stlport-tools.jam Mon Dec 13 19:14:18 2004 @@ -40,7 +40,7 @@ } case *BSD : { - flags gcc LINKFLAGS <stlport-iostream>on : -pthread ; + flags gcc LINKFLAGS <stlport-iostream>on : %%PTHREAD_LIBS%% ; } case IRIX : {
But for these sorts of changes to work generically it would be better to condition specifically on FreeBSD, after all there are other BSDs out there. For example instead of the above: case FreeBSD : { flags gcc LINKFLAGS <stlport-iostream>on : $(PTHREAD_LIBS) ; } case *BSD : { flags gcc LINKFLAGS <stlport-iostream>on : -pthread ; } You get the idea. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com - 102708583/icq
Rene Rivera wrote:
8Simon Barner wrote:
Starting with Boost v. 1.31.0, I intend to bump the shared library version number with every boost release in order to prevent from problems that are caused by ABI incompatiblities.
I think a better approach, given the linker requirements in FreeBSD, is to not remove the 1_32 tag, and set the so postfix to the patch revision. For example:
libboost_*-1_32.so.0
Which by the way is what the BBv1 OpenBSD build does.
I posted a question regrading this issue in the freebsd-ports list, but I have not recieved an answer yet. [...]
As mentioned by others you can use $(PTHREAD_LIBS) to get at the env variables, as all are mirrored by the build system.
Yes, thanks. I have already changed my port to reflect this. [...]
But for these sorts of changes to work generically it would be better to condition specifically on FreeBSD, after all there are other BSDs out there. For example instead of the above:
case FreeBSD : { flags gcc LINKFLAGS <stlport-iostream>on : $(PTHREAD_LIBS) ; } case *BSD : { flags gcc LINKFLAGS <stlport-iostream>on : -pthread ; }
The problem is that the PTHREAD_{LIBS,CFLAGS} variables are available in the ports framework only (which sets them according to the underlying FreeBSD version). If the boost distribution was changed to use those variables for FreeBSD, users no longer would be able to build Boost directly from the tarballs, which certainly is not desired. To sum this up: flags gcc LINKFLAGS ... : -pthread and flags gcc CFLAGS ... : is fine for recent versions of FreeBSD 5. The exact requirements would be .if ${OSVERSION} < 500016 PTHREAD_CFLAGS?= -D_THREAD_SAFE PTHREAD_LIBS?= -pthread .elif ${OSVERSION} < 502102 PTHREAD_CFLAGS?= -D_THREAD_SAFE PTHREAD_LIBS?= -lc_r .else PTHREAD_CFLAGS?= PTHREAD_LIBS?= -pthread .endif but I doubt that this could be reflected directly in the jam file (or is there a way to query the exakt OS version?). IMO the best thing is to leave the jam files unchanged, and I will keep those tow patches in the ports collection in order to handle those special cases. This is not uncommon in the ports collection. Simon
Simon Barner wrote:
Rene Rivera wrote:
But for these sorts of changes to work generically it would be better to condition specifically on FreeBSD, after all there are other BSDs out there. For example instead of the above:
case FreeBSD : { flags gcc LINKFLAGS <stlport-iostream>on : $(PTHREAD_LIBS) ; } case *BSD : { flags gcc LINKFLAGS <stlport-iostream>on : -pthread ; }
The problem is that the PTHREAD_{LIBS,CFLAGS} variables are available in the ports framework only (which sets them according to the underlying FreeBSD version).
Well it could be changed so that it handles both situations, building outside of the ports framework and within it. By checking if the PTHREADS_LIBS, or some other var that is specific to the ports build, and providing code for both possibilities.
If the boost distribution was changed to use those variables for FreeBSD, users no longer would be able to build Boost directly from the tarballs, which certainly is not desired.
OK, I misunderstood, I thought that these where general requirements for building on FreeBSD.
To sum this up: flags gcc LINKFLAGS ... : -pthread and flags gcc CFLAGS ... : is fine for recent versions of FreeBSD 5.
The exact requirements would be
.if ${OSVERSION} < 500016 PTHREAD_CFLAGS?= -D_THREAD_SAFE PTHREAD_LIBS?= -pthread .elif ${OSVERSION} < 502102 PTHREAD_CFLAGS?= -D_THREAD_SAFE PTHREAD_LIBS?= -lc_r .else PTHREAD_CFLAGS?= PTHREAD_LIBS?= -pthread .endif
but I doubt that this could be reflected directly in the jam file (or is there a way to query the exakt OS version?).
Never fear... If you can deduce what you need to do from the output of "uname -a" you can do it. That is because the different parts of "uname -a" are reflected in the $(JAMUNAME) variable. For example on my OpenBSD JAMUNAME is: "OpenBSD" "red5of5" "3.2" "RED5OF5#2" "i386" So to get the OS version you do: $(JAMUNAME[3])
IMO the best thing is to leave the jam files unchanged, and I will keep those tow patches in the ports collection in order to handle those special cases. This is not uncommon in the ports collection.
Possibly, and it is your choice ;-) But ultimately it would be best to make sure we support any platform build requirements. And the above looks like it's a platform requirement to me as it pertains to the libraries used for threading support. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com - 102708583/icq
participants (2)
-
Aleksey Gurtovoy -
Beman Dawes -
Caleb Epstein -
Joel -
John Maddock -
larsbj＠gullik.net -
Rene Rivera -
Robert Ramey -
Simon Barner