Boost logo

Boost :

From: John Maddock (john_at_[hidden])
Date: 2005-01-06 08:04:19


> http://www.freebsd.org/cgi/cvsweb.cgi/~checkout~/ports/devel/boost/files/patch-boost%3a%3aconfig%3a%3aplatform%3absd.hpp?rev=1.1
>
> 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.

> 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.

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.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk