Hi there,
when boost1.53 got multiarched, all the libraries were moved to /usr/lib/<multi-arch-triplet>:
(saucy)andreas@incubator:~$ find /usr/lib -name libboost*
/usr/lib/x86_64-linux-gnu/libboost_python-py33.a
/usr/lib/x86_64-linux-gnu/libboost_python-py27.so.1.53.0
/usr/lib/x86_64-linux-gnu/libboost_python-py27.a
/usr/lib/x86_64-linux-gnu/libboost_python-py33.so.1.53.0
/usr/lib/x86_64-linux-gnu/libboost_python-py27.so
/usr/lib/x86_64-linux-gnu/libboost_python-py33.so
That works well for normal libraries, but the python one is a special case. As you can see, there are 2 libraries, one for python 2.7, one for 3.3. In the previous, non-multiarch, version, a symlink /usr/lib/libboost_python.so would be created to the default python version. Unfortunately the script didn't get adapted for the new location.
This breaks compilation of almost all programs that are linked against boost-python as well as auto-detection of boost for example in CMAKE: https://bugs.launchpad.net/bugs/1217106
Please see the attached patch for a possible solution. It sets the correct multi-arch location for the script during compilation and unbreaks CMAKE.
After a little talk on IRC, Dmitrijs proposed a different fix: Since the python2.7 release will be the latest in the 2.x series, the script that updates the symlink isn't necessary anymore and a static symlink can be used.