Boost logo

Boost :

From: Simon Barner (barner_at_[hidden])
Date: 2005-01-08 14:31:40


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




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