Hajime Saito(deleted)
08/24/2009 10:17 PM
post36589
|
Hello,
I have compiled boost 1.38.0. I'm not 100% sure that everthing is working. However, it seems to be cooperating with
OpenHRP so at least ublas and boost-filesystem seem to be okay. The main reason for this post is for others to poke
around and cross check.
I made the following changes to devel/boost-libs/Makefile
devel/boost-build/toolset.mk
devel/boost-jam/bjam.mk
Index: devel/boost-libs/Makefile
===================================================================
--- devel/boost-libs/Makefile (revision 219)
+++ devel/boost-libs/Makefile (working copy)
@@ -11,6 +11,9 @@
.include "../../meta-pkgs/boost/Makefile.common"
BJAM_ARGS+= --without-python
+BJAM_ARGS+= -sBZIP2_INCLUDE=/usr/pkg/include
+BJAM_ARGS+= -sBZIP2_LIBPATH=/usr/pkg/lib
+BJAM_ARGS+= -d +2
.include "../../devel/boost-jam/bjam.mk"
Index: devel/boost-build/toolset.mk
===================================================================
--- devel/boost-build/toolset.mk (revision 219)
+++ devel/boost-build/toolset.mk (working copy)
@@ -10,6 +10,8 @@
BOOST_TOOLSET= mipspro
.elif !empty(PKGSRC_COMPILER:Msunpro)
BOOST_TOOLSET= sunpro
+.elif !empty(PKGSRC_COMPILER:Mqcc)
+BOOST_TOOLSET= qcc
.else
PKG_FAIL_REASON+= "Unknown compiler ${PKGSRC_COMPILER} for Boost."
.endif
Index: devel/boost-jam/bjam.mk
===================================================================
--- devel/boost-jam/bjam.mk (revision 219)
+++ devel/boost-jam/bjam.mk (working copy)
@@ -21,6 +21,7 @@
BJAM_BUILD+= release
BJAM_BUILD+= threading=multi
BJAM_BUILD+= link=shared,static
+BJAM_BUILD+= "-sBUILD=<linkflags>-Wl,-rpath,/usr/pkg/lib"
BJAM_CMD= ${SETENV} ${MAKE_ENV} ${BJAM} ${BJAM_ARGS}
The changes I made to the boost source tree are attached in the file 'diff'.
However this was not enough to have linkable shared libraries. So in the end I made my own shell script with the
commands to do the linking.
The culprit in the linking stage was the fact that the shared libraries, that the library currently being linked relied
on were provided in the command line with the full path. So at run time, the library was searched for starting with the
full path and no amount of -rpath options could fix that.
I'm sure someone better than I can come up with a more elegant solution.
Best regards,
Hajime
|
Attachment: |
diff
5.05 KB
|
|
|