Boost logo

Boost :

From: Boris Gubenko (Boris.Gubenko_at_[hidden])
Date: 2006-12-20 18:41:24

  On a Unix system, Boost.Build creates dynamic libraries with ".so" suffix.
  However, on HP-UX, the Python interpreter expects ".sl". Here is an excerpt
  from Python configuration script:

echo "$as_me:$LINENO: checking SO" >&5
echo $ECHO_N "checking SO... $ECHO_C" >&6
if test -z "$SO"
  case $ac_sys_system in
  CYGWIN*) SO=.dll;;
  # this might also be a termcap variable, see #610332
  echo '===================================================================='
  echo '+ +'
  echo '+ WARNING: You have set SO in your environment. +'
  echo '+ Do you really mean to change the extension for shared libraries? +'
  echo '+ Continuing in 10 seconds to let you to ponder. +'
  echo '+ +'
  echo '===================================================================='
  sleep 10

  This represents a problem for boost python library tests creating extension
  files and invoking their respective python scripts to import these files.
  E.g. test args creates and invokes which imports
  args_ext. The import, obviously, does not work with, but
  works with

  I tried to build Python interpreter with SO variable defined as ".so".
  I got a clean build, but all Python self-tests failed. So, apparently,
  this SO business is a half-baked one. But even if I fixed the Python
  interpreter to support SO, it would be unreasonable to request HP-UX
  customers to use specially built Python with boost.

  To work around this problem, I modified action in acc.jam
  to change suffix in the -o string when appropriate. Specifically,
  instead of:

        -o "$(<[1])"

  the link command says:

        -o "`echo $(<[1]) | sed '/\/libs\/.*\/test\//s/\.so$/.sl/'`"

  It does the trick and 46 python library tests that used to fail because
  of this issue now pass, as well as python_test from parameter library.

  Is there a better solution to this problem?

  I tried to understand where ".so" suffix gets added, starting with
  python.jam, but could not see it.

  In BBv1, there was allyourbase.jam file defining SUFDLL variable depending
  on platform. Invoking bjam with would override the default.
  Does a similar mechanism exist in BBv2?


Boost list run by bdawes at, gregod at, cpdaniel at, john at