[boost] [python] a problem with suffix for shared libraries on HP-UX

20 Dec 2006

      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"
then
  case $ac_sys_system in
  hp*|HP*)   SO=.sl;;
  CYGWIN*)   SO=.dll;;
  *)   SO=.so;;
  esac
else
  # this might also be a termcap variable, see #610332
  echo
  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
fi

  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 args_ext.so and invokes args.py which imports
  args_ext. The import, obviously, does not work with args_ext.so, but
  works with args_ext.sl.

  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 acc.link.dll 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 -sSUFDLL=.sl would override the default.
  Does a similar mechanism exist in BBv2?

  Thanks,
    Boris

[boost] [python] a problem with suffix for shared libraries on HP-UX

Boris Gubenko