Build issue with boost::python

graph-tool
1

Hi.

I've looked at previous posts based on similar issues but cannot find
anything useful.

I have built boost (1.53.0) using a shared python (2.7) build i built
myself. I tried both default boost build as well as ./b2 -j 9
link=static,shared threading=multi

However it still fails to build.

config.log here: https://dpaste.de/dAIW

Input would be appreciated as I can only build in this way without a
package manager.

Also note that i had to change some lines in the configure to get it to
this point already.

Namely -Wno-unused-local-typedefs and -std=gnu++0x

I'm using gcc (GCC) 4.1.2 20080704 (Red Hat 4.1.2-48) on RHEL 5.5

attachment.html (889 Bytes)

2

Hi.

I've looked at previous posts based on similar issues but cannot find anything useful.

I have built boost (1.53.0) using a shared python (2.7) build i built myself. I tried both default boost build as well as ./b2 -j 9 link=static,shared threading=multi

However it still fails to build.

config.log here: https://dpaste.de/dAIW

From your log file:

    /usr/bin/ld: cannot find -lboost_python-mt-2.7

So, the linker cannot find the boost python library, probably because it
has some unexpected name, or because you haven't specified the correct
link paths. Also consider using the --with-boost-python option.

Input would be appreciated as I can only build in this way without a package manager.

Also note that i had to change some lines in the configure to get it to this point already.

Namely -Wno-unused-local-typedefs and -std=gnu++0x

I'm using gcc (GCC) 4.1.2 20080704 (Red Hat 4.1.2-48) on RHEL 5.5

I don't think you will be able to compile graph-tool with GCC 4.1... I
think you need at least GCC 4.4.

Best,
Tiago

3

Hi Tiago

Yes, but no matter what way i build boost it doesn't build libs with -mt:

$ find /home/gs/c/lib/boost-1.53.0//lib | grep python
/home/gs/c/lib/boost-1.53.0//lib/libboost_python.so
/home/gs/c/lib/boost-1.53.0//lib/libboost_python.so.1.53.0
/home/gs/c/lib/boost-1.53.0//lib/libboost_python.a

I thought the -mt lib files are actually a debian packaging thing and not
something created by boost

Perhaps i could sym link them all?

attachment.html (2.66 KB)

4

-mt suffix was a deprecated compact symlink in Debian boost for a while now
& it's now been removed.

from mobile.

attachment.html (2.92 KB)

5

You have to use the --with-boost-python option to pass the exact name of
the boost-python library.

Best,
Tiago

6

Hi Tiago

I did try that and got to to some more errors caused by linking from boost.
I removed these by compiling python with ucs4 support as well.

That leaves one remaining error in the graph-toolconfig.log:

configure:17532: g++ -o conftest -Wall -Wextra -Wno-unused-parameter
-ftemplate-depth-150 -Wno-deprecated -Wno-unknown-pragmas -O3
-fvisibility=default -fvisibility-inlines-hidden -Wno-unknown-pragmas
-I/home/gs/Python-2.7.6/python-2.7.6-shared-ucs4/include/python2.7
-L/home/gs/Python-2.7.6/python-2.7.6-shared-ucs4/lib/
-L/home/gs/Python-2.7.6/python-2.7.6-shared-ucs4/lib -lpython2.7
conftest.cpp -lboost_python -lm >&5

/usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../lib64/libboost_python.so:
undefined reference to `Py_InitModule4'

attachment.html (2.33 KB)

7

It seems like the boost_python which is being linked against belongs to the
system (in /usr/lib64), but you are using your own python library. Was
boost python in the system directory linked against your own python? It
seems not...

Best,
Tiago

8

Thanks I failed to spot that.

I intend to completely ignore that install of boost, so I'm not sure why it
is finding it there.

I've run configure with:

./configure --prefix=/home/gs/graph-tool-2.2.27/gt-rbsinst
--with-boost=/home/gs/c/lib/boost.1.53.0-sopy-ucs4/
LDFLAGS=-L/home/gs/Python-2.7.6/python-2.7.6-shared-ucs4/lib

Why then is the graph-tool configure finding it and not the one under the
--with-boost= parameter

attachment.html (2.17 KB)

9

The configure script finds the include paths, but the compiler/linker
still need to known where the binaries are. This is done via the
LDFLAGS. You only passed the path to the python library, but you need to
pass the path to the boost libraries as well.

Best,
Tiago

10

Thanks Tiago

I assumed for some reason that those paths would be taken care of by
--with-boost

However after building numpy and then attempting to build scipy and finding
it needs BLAS which is written in fortran I have stopped trying to get
graph-tool to work. There are far too many dependencies for it to be a
reasonable product for my use case. I'll revert to boost-graph directly in
c++ for my needs.

Many thanks for your help in trying to get this to work.

Thanks
Gerry

attachment.html (1.89 KB)

11

Thanks Tiago

I assumed for some reason that those paths would be taken care of by --with-boost

However after building numpy and then attempting to build scipy and finding it needs BLAS which is written in fortran I have stopped trying to get graph-tool to work. There are far too many dependencies for it to be a reasonable product for my use case. I'll revert to boost-graph directly in c++ for my needs.

That's fine. Package dependencies is a problem which best solved by
computers, not humans.

Scipy is a standard framework for doing scientific analysis with
python. It is available in any distribution I known of.

Essentially the problem here is that you are trying to do by hand what
your operating system does for free, and what your system administrator
is paid to do (I hope). Unfortunately, this seems like a rather common
scenario... Nevertheless, the real problem is that you are stuck with an
ancient operating system, with no sysadmin rights. It is not a problem
with the "product", as I see it.

The single most frequent complain I hear about graph-tool is that it is
difficult to install because of the dependencies. The dependencies are
all standard software, available in all systems with some form of
package management. I even provide pre-compiled packages for some of
these systems. What else should I do?

From my perspective, it doesn't make any sense do drop an essential and

very useful thing like interoperability with scipy/numpy because people
can't install it by hand...

Best,
Tiago