10

I'd like to know what version of python boost_python.so is expecting. This is on a computer with multiple python versions and I did not build/install boost myself (nor do i have root access).

How can i tell what version of python boost_python.so is compiled for?

I didn't find anything useful in the output from ldd but include it here incase someone else sees something.

-bash-3.2$ ldd -v libboost_python.so.1.46.1 
libutil.so.1 => /lib64/libutil.so.1 (0x00002ad65582d000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00002ad655a30000)
libdl.so.2 => /lib64/libdl.so.2 (0x00002ad655c4b000)
librt.so.1 => /lib64/librt.so.1 (0x00002ad655e50000)
libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00002ad656059000)
libm.so.6 => /lib64/libm.so.6 (0x00002ad656359000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00002ad6565dd000)
libc.so.6 => /lib64/libc.so.6 (0x00002ad6567eb000)
/lib64/ld-linux-x86-64.so.2 (0x000000374c600000)

Version information:
./libboost_python.so.1.46.1:
    libgcc_s.so.1 (GCC_3.0) => /lib64/libgcc_s.so.1
    libpthread.so.0 (GLIBC_2.2.5) => /lib64/libpthread.so.0
    libc.so.6 (GLIBC_2.4) => /lib64/libc.so.6
    libc.so.6 (GLIBC_2.2.5) => /lib64/libc.so.6
    libstdc++.so.6 (CXXABI_1.3) => /usr/lib64/libstdc++.so.6
    libstdc++.so.6 (GLIBCXX_3.4) => /usr/lib64/libstdc++.so.6
/lib64/libutil.so.1:
    libc.so.6 (GLIBC_2.2.5) => /lib64/libc.so.6
/lib64/libpthread.so.0:
    ld-linux-x86-64.so.2 (GLIBC_2.3) => /lib64/ld-linux-x86-64.so.2
    ld-linux-x86-64.so.2 (GLIBC_2.2.5) => /lib64/ld-linux-x86-64.so.2
    ld-linux-x86-64.so.2 (GLIBC_PRIVATE) => /lib64/ld-linux-x86-64.so.2
    libc.so.6 (GLIBC_2.3.2) => /lib64/libc.so.6
    libc.so.6 (GLIBC_PRIVATE) => /lib64/libc.so.6
    libc.so.6 (GLIBC_2.2.5) => /lib64/libc.so.6
/lib64/libdl.so.2:
    ld-linux-x86-64.so.2 (GLIBC_PRIVATE) => /lib64/ld-linux-x86-64.so.2
    libc.so.6 (GLIBC_PRIVATE) => /lib64/libc.so.6
    libc.so.6 (GLIBC_2.2.5) => /lib64/libc.so.6
/lib64/librt.so.1:
    ld-linux-x86-64.so.2 (GLIBC_PRIVATE) => /lib64/ld-linux-x86-64.so.2
    libpthread.so.0 (GLIBC_2.2.5) => /lib64/libpthread.so.0
    libpthread.so.0 (GLIBC_PRIVATE) => /lib64/libpthread.so.0
    libc.so.6 (GLIBC_2.3.2) => /lib64/libc.so.6
    libc.so.6 (GLIBC_2.2.5) => /lib64/libc.so.6
    libc.so.6 (GLIBC_PRIVATE) => /lib64/libc.so.6
/usr/lib64/libstdc++.so.6:
    ld-linux-x86-64.so.2 (GLIBC_2.3) => /lib64/ld-linux-x86-64.so.2
    libgcc_s.so.1 (GCC_4.2.0) => /lib64/libgcc_s.so.1
    libgcc_s.so.1 (GCC_3.3) => /lib64/libgcc_s.so.1
    libgcc_s.so.1 (GCC_3.0) => /lib64/libgcc_s.so.1
    libc.so.6 (GLIBC_2.3.2) => /lib64/libc.so.6
    libc.so.6 (GLIBC_2.4) => /lib64/libc.so.6
    libc.so.6 (GLIBC_2.3) => /lib64/libc.so.6
    libc.so.6 (GLIBC_2.2.5) => /lib64/libc.so.6
/lib64/libm.so.6:
    libc.so.6 (GLIBC_2.2.5) => /lib64/libc.so.6
/lib64/libgcc_s.so.1:
    libc.so.6 (GLIBC_2.4) => /lib64/libc.so.6
    libc.so.6 (GLIBC_2.2.5) => /lib64/libc.so.6
/lib64/libc.so.6:
    ld-linux-x86-64.so.2 (GLIBC_2.3) => /lib64/ld-linux-x86-64.so.2
    ld-linux-x86-64.so.2 (GLIBC_PRIVATE) => /lib64/ld-linux-x86-64.so.2
Anthony Bak
  • 1,123
  • 3
  • 10
  • 16

4 Answers4

3

Is this what you are looking for?

~/Desktop$ dpkg --list | grep libboost
ii  libboost-filesystem1.46.1                      1.46.1-5ubuntu2                         filesystem operations (portable paths, iteration over directories, etc) in C++
ii  libboost-program-options1.46.1                 1.46.1-5ubuntu2                         program options library for C++
ii  libboost-python-dev                            1.46.1.1                                Boost.Python Library development files (default version)
ii  libboost-python1.46-dev                        1.46.1-5ubuntu2                         Boost.Python Library development files
ii  libboost-python1.46.1                          1.46.1-5ubuntu2                         Boost.Python Library
ii  libboost-regex1.46.1                           1.46.1-5ubuntu2                         regular expression library for C++
ii  libboost-serialization1.46.1                   1.46.1-5ubuntu2                         serialization library for C++
ii  libboost-signals1.46.1                         1.46.1-5ubuntu2                         managed signals and slots library for C++
ii  libboost-system1.46.1                          1.46.1-5ubuntu2                         Operating system (e.g. diagnostics support) library
ii  libboost-thread1.46.1                          1.46.1-5ubuntu2                         portable C++ multi-threading
ii  libboost1.46-dev                               1.46.1-5ubuntu2                         Boost C++ Libraries development files

The above works for debian-based distros. I believe the equivalent for Fedora should be:

rpm -qa | grep libboost

HTH!

mac
  • 42,153
  • 26
  • 121
  • 131
3

From: https://github.com/mapnik/mapnik/wiki/InstallationTroubleshooting

"And sometimes even that does not work. HINT: pass the -d2 flag to see all the compile commands sent to gcc by bjam and you will likely see something like -I/usr/include/python24 in the compile arguments when it should be -I/usr/include/python26 (or some older version of python headers). If this happens then you can craft a full config file (with all possible python info) and pass a reference to that on the bjam command line. Docs on this are here: http://www.boost.org/doc/libs/1_42_0/libs/python/doc/building.html#configuring-boost-build, and an example follows:

Create a file called 'user-config.jam' (but change the python versions to be appropriate):

import option ;
import feature ;
if ! gcc in [ feature.values <toolset> ]
{
    using gcc ;
}
project : default-build <toolset>gcc ;
using python
     : 2.5 # version
     : /usr/bin/python2.5 # cmd-or-prefix
     : /usr/include/python2.5/ # includes
     : /usr/lib/python2.5/config/ # a lib actually symlink
     : <toolset>gcc # condition
     ;
libraries = --with-python ;

"

Look for a .jam config file. If it exists check for the 'using python' command. If it doesn't exist, run the -d2 flag against bjam to determine the default location of python that it uses. This obviously isn't a direct method and would simply leave you with a likely answer given the inputs (but maybe that's good enough).

sgallen
  • 2,079
  • 13
  • 10
  • This is in a cluster environment and I suspect boost was installed from source but compiled on a machine that i don't have access to (there's no bjam on the machine for instance). I suspect that I need a way to extract if from the boost libraries directly. – Anthony Bak Dec 22 '11 at 22:25
1

I realize the OP was asking about how to do this in a Linux environment, but I had the same question in a Windows environment, and thought it may be helpful information to share here.

To see the Python DLL that will be auto-linked into the resulting executable, use the dumpbin utility that comes with Visual Studio. Simply open a Visual Studio developer command prompt, and run:

dumpbin /DIRECTIVES libboost_python3-*.lib | findstr DEFAULTLIB:python

That will at least tell you the major/minor version of Python that was used when building Boost. For example, if you used Python 3.5.2 when building Boost, this command would return a bunch of lines with the text:

/DEFAULTLIB:python35.lib

Jeff G
  • 4,470
  • 2
  • 41
  • 76
0

Interestingly, on my OS X system, otool -L does list the python library, but on the linux system I have access to it seems to be left as an unmet dependency, and isn't listed in the ldd output.

In my case, I know it was compiled against python 2.7, but a check of the output of strings /.../libboost_python.so reveals no mention of 2.7, and 27 only occurs in mangled symbols unrelated to the python version.

So I conclude that it isn't possible to tell, without looking for API differences in symbols between, say, 2.6, 2.7 versions.

Perhaps checking the modified timestamp would narrow it down?

James
  • 24,676
  • 13
  • 84
  • 130
  • I'm accepting this answer because none of the other answers work for me. Theoretically it has to be possible somehow but nobody seems to know how.... – Anthony Bak Aug 28 '12 at 21:21