Hi, The macports libtool is 2.2.6b and seems to work fine, so it was a bit puzzling why there was any problem at all. After looking through the configure script, at the end you have some lines to correct a problem with linking the stdc++ library- it simply reads the libtool script, pipes it through sed and writes it back again. This is what causes the problems with libtool- the shell script is doing some interpretation of the libtool script as it reads it and when you write it back again, and some of the elaborate quoting of strings is changed. You might try this patch on osx which removes the sed replacements in the configure.ac file. I think things should work ok on osx without this- I have no idea how you enable this conditionally on osx... It is nice that the 64bit support is there. At the moment I have only built it with 32bit on osx. I had thought that things were working ok, but I had compiled the graph-tool library with a different compiler version to my python libraries- so I have to compile over again... I have encountered another few problems with the default compiler on osx (gcc-4.2) which does not like the tr1::random functions- I got round this by converting tr1::random to boost::random which seems to work just fine (I'm using boost 1.41). A major problem with trying to work on graph-tool is that the whole library seems to take an extraordinary amount of time (and memory) to compile (given the amount of code). I assume this is because of the sophisticated use of template meta-programming. Is there any way to reduce the compile times? Has anyone used precompiled headers? Do they help? regards, tcb --- configure.ac.bak 2010-01-25 08:05:51.000000000 +0000 +++ configure.ac 2010-01-25 08:06:00.000000000 +0000 @@ -325,6 +325,6 @@ # __cxa_allocate_exception() see: # http://www.nabble.com/preventing-boost::python::throw_error_already_set-td20... # http://wiki.fifengine.de/Segfault_in_cxa_allocate_exception -AC_MSG_NOTICE([Modifying libtool to correctly link libstdc++ before anything else...]) -libtool=`cat libtool | sed "s/-nostdlib/-nostdlib -lstdc++/g"` -echo "$libtool" > libtool +#AC_MSG_NOTICE([Modifying libtool to correctly link libstdc++ before anything else...]) +#libtool=`cat libtool | sed "s/-nostdlib/-nostdlib -lstdc++/g"` +#echo "$libtool" > libtool On Fri, Jan 22, 2010 at 7:58 AM, Tiago de Paula Peixoto <tiago@forked.de> wrote:
Hi tcb,
Thanks a lot for taking the time to do this! I don't have macos myself, so I could not fix those issues. I planned to install it on a VM on my laptop, but never got around to it due to lack of time.
I'll include your patches, but first I have to understand this libtool thing. I generated the tarballs with libtool version 2.2.6b, which as far as I know is the newest one, so what you are using must be a specific non-official modification for macos. The libtool script (ltmain.sh) is not included in graph-tool itself, and is generated (copied from the system) when the tarball is created. I don't know hot to include it, other than generating the tarball in a macos environment...
Could you guys check if you run ./autogen.sh (with the git version of graph-tool) before building the package solves the libtool issue without copying it by hand? Could you also send me the ltmain.sh/libtool script you use?
There are some more answers below.
On 01/22/2010 01:25 AM, tcb wrote:
That's a great idea to take it into macports. I am only just checking out graph-tool and it looks really nice, and a macports would certainly be very useful. It also doesnt seem like it would be too much work- I'm sure the macports guys would help out with the autotools configuration- and other than the numpy patch it seems to compile and run just fine on the mac. I have only compiled it 32-bit with gcc44- I have not tried a 64-bit compile and I dont know if its written to be 64bit safe (this would be very nice if it was). There don't seem to be any tests which would be helpful in verifying that the port was working- but a 32bit macport would be a start at least.
64 bit should not be a problem at all, and I use it on 64 bit machines all the time.
I initially found this project when I was looking for a working version of the python bindings for the boost graph library- development seems to be discontinued for some time. Can anyone confirm if graph-tool is effectively a customised python binding for the bgl? What would be involved in updating the python bgl bindings?
I think graph-tool works as an effective python binding for the bgl, even though there are some algorithms there which are not (at this time) in the BGL, such as random graph generation, rewiring, community detection, triangulation and others. There are also some algorithms in the BGL which are not reflected in graph-tool, but I'm in the gradual process of incorporating them.
Regarding python-bgl, I believe all it needs is a maintainer, since no one seems to be interested. The actual implementation is quite different from graph-tool, since they opt for a list-based adjacency list (which can be a performance killer) and try to be very close to the C++ API. In graph-tool I kept a certain distance from it to make things more comfortable in the python side (for instance, property map handling is way easier in graph-tool IMHO), and included other nice things such as graph filtering.
Thanks again for helping out!
Cheers, Tiago
_______________________________________________ graph-tool mailing list graph-tool@forked.de http://lists.forked.de/mailman/listinfo/graph-tool