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
On 01/06/2014 03:05 PM, Gerry Steele wrote:
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 -- Tiago de Paula Peixoto <tiago@skewed.de>
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? On Monday, January 6, 2014 4:41:27 PM UTC, Tiago Peixoto wrote:
On 01/06/2014 03:05 PM, Gerry Steele wrote:
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
-- Tiago de Paula Peixoto <ti...@skewed.de <javascript:>>
-mt suffix was a deprecated compact symlink in Debian boost for a while now & it's now been removed. from mobile. On 7 Jan 2014 08:14, "Gerry Steele" <gerry.steele@gmail.com> wrote:
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?
On Monday, January 6, 2014 4:41:27 PM UTC, Tiago Peixoto wrote:
On 01/06/2014 03:05 PM, Gerry Steele wrote:
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
-- Tiago de Paula Peixoto <ti...@skewed.de>
_______________________________________________ graph-tool mailing list graph-tool@skewed.de http://lists.skewed.de/mailman/listinfo/graph-tool
On 01/07/2014 09:13 AM, Gerry Steele wrote:
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?
You have to use the --with-boost-python option to pass the exact name of the boost-python library. Best, Tiago -- Tiago de Paula Peixoto <tiago@skewed.de>
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' On Tuesday, January 7, 2014 9:00:24 AM UTC, Tiago Peixoto wrote:
On 01/07/2014 09:13 AM, Gerry Steele wrote:
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?
You have to use the --with-boost-python option to pass the exact name of the boost-python library.
Best, Tiago
-- Tiago de Paula Peixoto <ti...@skewed.de <javascript:>>
On 01/07/2014 11:26 AM, Gerry Steele wrote:
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'
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 -- Tiago de Paula Peixoto <tiago@skewed.de>
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 On Tuesday, January 7, 2014 2:00:02 PM UTC, Tiago Peixoto wrote:
On 01/07/2014 11:26 AM, Gerry Steele wrote:
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'
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
-- Tiago de Paula Peixoto <ti...@skewed.de <javascript:>>
On 01/07/2014 03:29 PM, Gerry Steele wrote:
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
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 -- Tiago de Paula Peixoto <tiago@skewed.de>
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 On Tuesday, January 7, 2014 2:39:39 PM UTC, Tiago Peixoto wrote:
On 01/07/2014 03:29 PM, Gerry Steele wrote:
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
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
-- Tiago de Paula Peixoto <ti...@skewed.de <javascript:>>
On 01/07/2014 04:48 PM, Gerry Steele wrote:
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 -- Tiago de Paula Peixoto <tiago@skewed.de>
participants (3)
-
Dimitri John Ledkov -
Gerry Steele -
Tiago de Paula Peixoto