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