tcb | 21 Jan 2010 22:39
Picon

building graph-tool under Mac OS X

Hi,


I dont know if graph-tool is fully supported under macosx, but I have encountered a few problems with building it (on osx 10.6). The problems seem to stem from the configure/libtool scripts- about which I know very little- but I have figured out enough to get it to build. I noticed the same problem was reported on this list back in October (was it ever resolved?) - the errors were along the lines of "configure: error: No usable boost::python found". This problem would seem to be solved by modifying the configure script, which tries to link against the boost libraries with libboost-python*.[so,a] extensions- on osx I have compiled boost as a shared library and so it should look for libboost-python*.[dylib]. There is a patch for the configure script below. I also found some problems with the libtool script, so I replaced it with libtool (from the macports libtool package) (cp /opt/local/bin/glibtool ~/src/graph-tool/libtool) and the build proceeded to completion. This patch just gets the build working- I dont really know where the configure script gets the [so,a] information from, and its old version of libtool- the proper fix would address these issues.

There was also a problem I encountered with numpy_bind.hh when compiling with gcc44 (from macports). The fix was to add another element to the numpy_types map- the patch is also below.

regards,

tcb

--- configure~ 2010-01-21 05:30:22.000000000 +0000 +++ configure 2010-01-21 05:41:37.000000000 +0000 <at> <at> -16695,7 +16695,7 <at> <at> BOOSTLIBDIR=`echo $BOOST_LDFLAGS | sed -e 's/[^\/]*//'` if test "x$ax_boost_user_iostreams_lib" = "x"; then - for libextension in `ls $BOOSTLIBDIR/libboost_iostreams*.{so,a}* 2>/dev/null | sort -r | sed 's,.*/,,' | sed -e 's;^lib\(boost_iostreams.*\)\.so.*$;\1;' -e 's;^lib\(boost_iostreams.*\)\.a*$;\1;'` ; do + for libextension in `ls $BOOSTLIBDIR/libboost_iostreams*.{dylib,a}* 2>/dev/null | sort -r | sed 's,.*/,,' | sed -e 's;^lib\(boost_iostreams.*\)\.dylib.*$;\1;' -e 's;^lib\(boost_iostreams.*\)\.a*$;\1;'` ; do ax_lib=${libextension} as_ac_Lib=`$as_echo "ac_cv_lib_$ax_lib''_exit" | $as_tr_sh` { $as_echo "$as_me:${as_lineno-$LINENO}: checking for exit in -l$ax_lib" >&5 <at> <at> -16926,7 +16926,7 <at> <at> BOOSTLIBDIR=`echo $BOOST_LDFLAGS | sed -e 's/[^\/]*//'` if test "x$ax_boost_user_regex_lib" = "x"; then - for libextension in `ls $BOOSTLIBDIR/libboost_regex*.{so,a}* 2>/dev/null | sort -r | sed 's,.*/,,' | sed -e 's;^lib\(boost_regex.*\)\.so.*$;\1;' -e 's;^lib\(boost_regex.*\)\.a*$;\1;'` ; do + for libextension in `ls $BOOSTLIBDIR/libboost_regex*.{dylib,a}* 2>/dev/null | sort -r | sed 's,.*/,,' | sed -e 's;^lib\(boost_regex.*\)\.dylib.*$;\1;' -e 's;^lib\(boost_regex.*\)\.a*$;\1;'` ; do ax_lib=${libextension} as_ac_Lib=`$as_echo "ac_cv_lib_$ax_lib''_exit" | $as_tr_sh` { $as_echo "$as_me:${as_lineno-$LINENO}: checking for exit in -l$ax_lib" >&5


--- a/src/graph/numpy_bind.hh +++ b/src/graph/numpy_bind.hh <at> <at> -50,13 +50,16 <at> <at> typedef mpl::map< mpl::pair<int64_t, mpl::int_<NPY_INT64> >, mpl::pair<uint64_t, mpl::int_<NPY_UINT64> >, mpl::pair<double, mpl::int_<NPY_DOUBLE> >, - mpl::pair<long double, mpl::int_<NPY_LONGDOUBLE> > + mpl::pair<long double, mpl::int_<NPY_LONGDOUBLE> >, + mpl::pair<unsigned long int, mpl::int_<NPY_ULONG> > > numpy_types;

_______________________________________________
graph-tool mailing list
graph-tool <at> forked.de
http://lists.forked.de/mailman/listinfo/graph-tool
Claudio Martella | 22 Jan 2010 00:15
Picon
Gravatar

Re: building graph-tool under Mac OS X

Thanks for the patch! I was the one taking out the issue. I also
managed to solve the libtool problem but i got stuck to the numpy
issue. I'll check out your second patch. Thanks again!
BTW i think we should create a macport of this lib!

On Thu, Jan 21, 2010 at 10:39 PM, tcb <thecolourblue+m <at> gmail.com> wrote:
> Hi,
> I dont know if graph-tool is fully supported under macosx, but I have
> encountered a few problems with building it (on osx 10.6). The problems seem
> to stem from the configure/libtool scripts- about which I know very little-
> but I have figured out enough to get it to build. I noticed the same problem
> was reported on this list back in October (was it ever resolved?) - the
> errors were along the lines of "configure: error: No usable boost::python
> found". This problem would seem to be solved by modifying the configure
> script, which tries to link against the boost libraries with
> libboost-python*.[so,a] extensions- on osx I have compiled boost as a shared
> library and so it should look for libboost-python*.[dylib]. There is a patch
> for the configure script below. I also found some problems with the libtool
> script, so I replaced it with libtool (from the macports libtool package)
> (cp /opt/local/bin/glibtool ~/src/graph-tool/libtool) and the build
> proceeded to completion. This patch just gets the build working- I dont
> really know where the configure script gets the [so,a] information from, and
> its old version of libtool- the proper fix would address these issues.
> There was also a problem I encountered with numpy_bind.hh when compiling
> with gcc44 (from macports). The fix was to add another element to the
> numpy_types map- the patch is also below.
> regards,
> tcb
> --- configure~ 2010-01-21 05:30:22.000000000 +0000 +++ configure 2010-01-21
> 05:41:37.000000000 +0000  <at>  <at>  -16695,7 +16695,7  <at>  <at>  BOOSTLIBDIR=`echo
> $BOOST_LDFLAGS | sed -e 's/[^\/]*//'` if test
> "x$ax_boost_user_iostreams_lib" = "x"; then - for libextension in `ls
> $BOOSTLIBDIR/libboost_iostreams*.{so,a}* 2>/dev/null | sort -r | sed
> 's,.*/,,' | sed -e 's;^lib\(boost_iostreams.*\)\.so.*$;\1;' -e
> 's;^lib\(boost_iostreams.*\)\.a*$;\1;'` ; do + for libextension in `ls
> $BOOSTLIBDIR/libboost_iostreams*.{dylib,a}* 2>/dev/null | sort -r | sed
> 's,.*/,,' | sed -e 's;^lib\(boost_iostreams.*\)\.dylib.*$;\1;' -e
> 's;^lib\(boost_iostreams.*\)\.a*$;\1;'` ; do ax_lib=${libextension}
> as_ac_Lib=`$as_echo "ac_cv_lib_$ax_lib''_exit" | $as_tr_sh` { $as_echo
> "$as_me:${as_lineno-$LINENO}: checking for exit in -l$ax_lib" >&5  <at>  <at> 
> -16926,7 +16926,7  <at>  <at>  BOOSTLIBDIR=`echo $BOOST_LDFLAGS | sed -e 's/[^\/]*//'`
> if test "x$ax_boost_user_regex_lib" = "x"; then - for libextension in `ls
> $BOOSTLIBDIR/libboost_regex*.{so,a}* 2>/dev/null | sort -r | sed 's,.*/,,' |
> sed -e 's;^lib\(boost_regex.*\)\.so.*$;\1;' -e
> 's;^lib\(boost_regex.*\)\.a*$;\1;'` ; do + for libextension in `ls
> $BOOSTLIBDIR/libboost_regex*.{dylib,a}* 2>/dev/null | sort -r | sed
> 's,.*/,,' | sed -e 's;^lib\(boost_regex.*\)\.dylib.*$;\1;' -e
> 's;^lib\(boost_regex.*\)\.a*$;\1;'` ; do ax_lib=${libextension}
> as_ac_Lib=`$as_echo "ac_cv_lib_$ax_lib''_exit" | $as_tr_sh` { $as_echo
> "$as_me:${as_lineno-$LINENO}: checking for exit in -l$ax_lib" >&5
>
> --- a/src/graph/numpy_bind.hh +++ b/src/graph/numpy_bind.hh  <at>  <at>  -50,13 +50,16
>  <at>  <at>  typedef mpl::map< mpl::pair<int64_t, mpl::int_<NPY_INT64> >,
> mpl::pair<uint64_t, mpl::int_<NPY_UINT64> >, mpl::pair<double,
> mpl::int_<NPY_DOUBLE> >, - mpl::pair<long double, mpl::int_<NPY_LONGDOUBLE>
>> + mpl::pair<long double, mpl::int_<NPY_LONGDOUBLE> >, + mpl::pair<unsigned
> long int, mpl::int_<NPY_ULONG> > > numpy_types;
>
> _______________________________________________
> graph-tool mailing list
> graph-tool <at> forked.de
> http://lists.forked.de/mailman/listinfo/graph-tool
>
>

--

-- 
    Claudio Martella
    claudio.martella <at> gmail.com
tcb | 22 Jan 2010 01:25
Picon

Re: building graph-tool under Mac OS X

Hi,

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.

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?

regards,

tcb

On Thu, Jan 21, 2010 at 11:15 PM, Claudio Martella
<claudio.martella <at> gmail.com> wrote:
>
> Thanks for the patch! I was the one taking out the issue. I also
> managed to solve the libtool problem but i got stuck to the numpy
> issue. I'll check out your second patch. Thanks again!
> BTW i think we should create a macport of this lib!
>
> On Thu, Jan 21, 2010 at 10:39 PM, tcb <thecolourblue+m <at> gmail.com> wrote:
> > Hi,
> > I dont know if graph-tool is fully supported under macosx, but I have
> > encountered a few problems with building it (on osx 10.6). The problems seem
> > to stem from the configure/libtool scripts- about which I know very little-
> > but I have figured out enough to get it to build. I noticed the same problem
> > was reported on this list back in October (was it ever resolved?) - the
> > errors were along the lines of "configure: error: No usable boost::python
> > found". This problem would seem to be solved by modifying the configure
> > script, which tries to link against the boost libraries with
> > libboost-python*.[so,a] extensions- on osx I have compiled boost as a shared
> > library and so it should look for libboost-python*.[dylib]. There is a patch
> > for the configure script below. I also found some problems with the libtool
> > script, so I replaced it with libtool (from the macports libtool package)
> > (cp /opt/local/bin/glibtool ~/src/graph-tool/libtool) and the build
> > proceeded to completion. This patch just gets the build working- I dont
> > really know where the configure script gets the [so,a] information from, and
> > its old version of libtool- the proper fix would address these issues.
> > There was also a problem I encountered with numpy_bind.hh when compiling
> > with gcc44 (from macports). The fix was to add another element to the
> > numpy_types map- the patch is also below.
> > regards,
> > tcb
> > --- configure~ 2010-01-21 05:30:22.000000000 +0000 +++ configure 2010-01-21
> > 05:41:37.000000000 +0000  <at>  <at>  -16695,7 +16695,7  <at>  <at>  BOOSTLIBDIR=`echo
> > $BOOST_LDFLAGS | sed -e 's/[^\/]*//'` if test
> > "x$ax_boost_user_iostreams_lib" = "x"; then - for libextension in `ls
> > $BOOSTLIBDIR/libboost_iostreams*.{so,a}* 2>/dev/null | sort -r | sed
> > 's,.*/,,' | sed -e 's;^lib\(boost_iostreams.*\)\.so.*$;\1;' -e
> > 's;^lib\(boost_iostreams.*\)\.a*$;\1;'` ; do + for libextension in `ls
> > $BOOSTLIBDIR/libboost_iostreams*.{dylib,a}* 2>/dev/null | sort -r | sed
> > 's,.*/,,' | sed -e 's;^lib\(boost_iostreams.*\)\.dylib.*$;\1;' -e
> > 's;^lib\(boost_iostreams.*\)\.a*$;\1;'` ; do ax_lib=${libextension}
> > as_ac_Lib=`$as_echo "ac_cv_lib_$ax_lib''_exit" | $as_tr_sh` { $as_echo
> > "$as_me:${as_lineno-$LINENO}: checking for exit in -l$ax_lib" >&5  <at>  <at> 
> > -16926,7 +16926,7  <at>  <at>  BOOSTLIBDIR=`echo $BOOST_LDFLAGS | sed -e 's/[^\/]*//'`
> > if test "x$ax_boost_user_regex_lib" = "x"; then - for libextension in `ls
> > $BOOSTLIBDIR/libboost_regex*.{so,a}* 2>/dev/null | sort -r | sed 's,.*/,,' |
> > sed -e 's;^lib\(boost_regex.*\)\.so.*$;\1;' -e
> > 's;^lib\(boost_regex.*\)\.a*$;\1;'` ; do + for libextension in `ls
> > $BOOSTLIBDIR/libboost_regex*.{dylib,a}* 2>/dev/null | sort -r | sed
> > 's,.*/,,' | sed -e 's;^lib\(boost_regex.*\)\.dylib.*$;\1;' -e
> > 's;^lib\(boost_regex.*\)\.a*$;\1;'` ; do ax_lib=${libextension}
> > as_ac_Lib=`$as_echo "ac_cv_lib_$ax_lib''_exit" | $as_tr_sh` { $as_echo
> > "$as_me:${as_lineno-$LINENO}: checking for exit in -l$ax_lib" >&5
> >
> > --- a/src/graph/numpy_bind.hh +++ b/src/graph/numpy_bind.hh  <at>  <at>  -50,13 +50,16
> >  <at>  <at>  typedef mpl::map< mpl::pair<int64_t, mpl::int_<NPY_INT64> >,
> > mpl::pair<uint64_t, mpl::int_<NPY_UINT64> >, mpl::pair<double,
> > mpl::int_<NPY_DOUBLE> >, - mpl::pair<long double, mpl::int_<NPY_LONGDOUBLE>
> >> + mpl::pair<long double, mpl::int_<NPY_LONGDOUBLE> >, + mpl::pair<unsigned
> > long int, mpl::int_<NPY_ULONG> > > numpy_types;
> >
> > _______________________________________________
> > graph-tool mailing list
> > graph-tool <at> forked.de
> > http://lists.forked.de/mailman/listinfo/graph-tool
> >
> >
>
>
>
> --
>    Claudio Martella
>    claudio.martella <at> gmail.com
> _______________________________________________
> graph-tool mailing list
> graph-tool <at> forked.de
> http://lists.forked.de/mailman/listinfo/graph-tool
Tiago de Paula Peixoto | 22 Jan 2010 08:58
Picon
Gravatar

Re: building graph-tool under Mac OS X

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 <at> forked.de
http://lists.forked.de/mailman/listinfo/graph-tool
tcb | 25 Jan 2010 09:30
Picon

Re: building graph-tool under Mac OS X

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
 <at>  <at>  -325,6 +325,6  <at>  <at> 
 # __cxa_allocate_exception() see:
 # http://www.nabble.com/preventing-boost::python::throw_error_already_set-td20958723.html
 # 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 <at> 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 <at> forked.de
> http://lists.forked.de/mailman/listinfo/graph-tool
>
>
Tiago de Paula Peixoto | 25 Jan 2010 10:09
Picon
Gravatar

Re: building graph-tool under Mac OS X

Hi,

On 01/25/2010 09:30 AM, tcb wrote:
> 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...

This is unfortunately necessary (at least on GNU/Linux) since there is
currently a problem with libtool/gcc when binaries are linked with
libstdc++ in a random order, which causes segfaults. The modification
ensures that libstdc++ gets linked first. What can be done, is to check
whether the corresponding line is there in the file, and only do the
modification if it looks exactly as expected, otherwise leave it alone.

> 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).

Be careful, there are some serious bugs with the boost random library!
Take a look at: http://lists.boost.org/boost-users/2009/05/48444.php

I switched to tr1, since the boost::random stuff seems a bit
abandoned. However the tr1 has not entirely stabilized yet, and you need
gcc 4.4 or newer to use it.

> 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?

Precompiled headers do not really help in this case, but I recommend
using ccache (http://ccache.samba.org), which works very well.

Otherwise you can also turn off graph filtering to save some time and
memory.

I hear GCC 4.5 will have improved template performance, since they
switched to O(1) instantiation, instead of O(N).

Cheers,
Tiago

_______________________________________________
graph-tool mailing list
graph-tool <at> forked.de
http://lists.forked.de/mailman/listinfo/graph-tool
tcb | 25 Jan 2010 11:05
Picon

Re: building graph-tool under Mac OS X

Hi,

On Mon, Jan 25, 2010 at 9:09 AM, Tiago de Paula Peixoto <tiago <at> forked.de> wrote:
> Hi,
>
> On 01/25/2010 09:30 AM, tcb wrote:
>> 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...
>
> This is unfortunately necessary (at least on GNU/Linux) since there is
> currently a problem with libtool/gcc when binaries are linked with
> libstdc++ in a random order, which causes segfaults. The modification
> ensures that libstdc++ gets linked first. What can be done, is to check
> whether the corresponding line is there in the file, and only do the
> modification if it looks exactly as expected, otherwise leave it alone.

Ok, you could use sed to edit the file in place, instead of reading it
as a string- something like:

  eval sed -i -e "s/-nostdlib/-nostdlib -lstdc++/g" libtool

>
>> 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).
>
> Be careful, there are some serious bugs with the boost random library!
> Take a look at: http://lists.boost.org/boost-users/2009/05/48444.php
>
> I switched to tr1, since the boost::random stuff seems a bit
> abandoned. However the tr1 has not entirely stabilized yet, and you need
> gcc 4.4 or newer to use it.
>

Oops, I hadn't seen that- I saw no indication that there were any such
problems with the boost random library (although this follow up mail
seems to suggest the problems were fixed as of 2009-05-30
http://lists.boost.org/boost-users/2009/05/48582.php). Unfortunately
there is very little information on what works in the tr1 libraries
across different compiler versions.

>> 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?
>
> Precompiled headers do not really help in this case, but I recommend
> using ccache (http://ccache.samba.org), which works very well.
>
> Otherwise you can also turn off graph filtering to save some time and
> memory.
>
> I hear GCC 4.5 will have improved template performance, since they
> switched to O(1) instantiation, instead of O(N).
>

Ok, that's good to hear. If I recompile with gcc-4.5 then I also need
to recompile my whole python stack with 4.5 too (including numpy and
scipy etc...)- so that is my motivation to get something working with
gcc-4.2.

> Cheers,
> Tiago
>

regards

>
> _______________________________________________
> graph-tool mailing list
> graph-tool <at> forked.de
> http://lists.forked.de/mailman/listinfo/graph-tool
>
>
Tiago de Paula Peixoto | 25 Jan 2010 14:17
Picon
Gravatar

Re: building graph-tool under Mac OS X

Hi

On 01/25/2010 11:05 AM, tcb wrote:
> Ok, you could use sed to edit the file in place, instead of reading it
> as a string- something like:
> 
>   eval sed -i -e "s/-nostdlib/-nostdlib -lstdc++/g" libtool

Indeed, this will probably solve the problem.

I committed all the necessary modifications to the git repository. Could
you please get the new git version, and see if it works for you?

>> Be careful, there are some serious bugs with the boost random library!
>> Take a look at: http://lists.boost.org/boost-users/2009/05/48444.php
>>
>> I switched to tr1, since the boost::random stuff seems a bit
>> abandoned. However the tr1 has not entirely stabilized yet, and you need
>> gcc 4.4 or newer to use it.
>>
> 
> Oops, I hadn't seen that- I saw no indication that there were any such
> problems with the boost random library (although this follow up mail
> seems to suggest the problems were fixed as of 2009-05-30
> http://lists.boost.org/boost-users/2009/05/48582.php). Unfortunately
> there is very little information on what works in the tr1 libraries
> across different compiler versions.

The tr1 should eventually stabilize, and things should change less and
less in the next versions... Boost::random on the other hand does not
seem to have he necessary maintenance a RNG library needs to have. Even
though the problem in question was fixed, it took quite some time for it
to be detected, and according to other people, it is still has some
other serious problems left.

>> I hear GCC 4.5 will have improved template performance, since they
>> switched to O(1) instantiation, instead of O(N).
>>
> 
> Ok, that's good to hear. If I recompile with gcc-4.5 then I also need
> to recompile my whole python stack with 4.5 too (including numpy and
> scipy etc...)- so that is my motivation to get something working with
> gcc-4.2.

No, it is not so drastic. There was a C++ ABI change after 4.2 (IIRC),
but the interface to C libraries (such as python, numpy, etc) should be
stable. You should only have to recompile the boost libraries. And if
you do it now with gcc 4.4, it should still be compatible with 4.5.

Cheers,
Tiago

_______________________________________________
graph-tool mailing list
graph-tool <at> forked.de
http://lists.forked.de/mailman/listinfo/graph-tool
tcb | 26 Jan 2010 01:38
Picon

Re: building graph-tool under Mac OS X

Hi,

Those changes look good, and fix the configure problems. It seems to
be compiling away just fine (I'll let you know in a day or so if it
finishes :) )

It is unfortunate about the boost random libraries- they seemed to me
very well designed, and they should be more carefully maintainted. I
am not so sure the tr1 random libraries are better maintained. Anyway,
it would only be an issue if we wanted to make a macport using the
gcc-4.2 compiler (which chokes on tr1::random).

On Mon, Jan 25, 2010 at 1:17 PM, Tiago de Paula Peixoto <tiago <at> forked.de> wrote:
> Hi
>
> On 01/25/2010 11:05 AM, tcb wrote:
>> Ok, you could use sed to edit the file in place, instead of reading it
>> as a string- something like:
>>
>>   eval sed -i -e "s/-nostdlib/-nostdlib -lstdc++/g" libtool
>
> Indeed, this will probably solve the problem.
>
> I committed all the necessary modifications to the git repository. Could
> you please get the new git version, and see if it works for you?
>
>>> Be careful, there are some serious bugs with the boost random library!
>>> Take a look at: http://lists.boost.org/boost-users/2009/05/48444.php
>>>
>>> I switched to tr1, since the boost::random stuff seems a bit
>>> abandoned. However the tr1 has not entirely stabilized yet, and you need
>>> gcc 4.4 or newer to use it.
>>>
>>
>> Oops, I hadn't seen that- I saw no indication that there were any such
>> problems with the boost random library (although this follow up mail
>> seems to suggest the problems were fixed as of 2009-05-30
>> http://lists.boost.org/boost-users/2009/05/48582.php). Unfortunately
>> there is very little information on what works in the tr1 libraries
>> across different compiler versions.
>
> The tr1 should eventually stabilize, and things should change less and
> less in the next versions... Boost::random on the other hand does not
> seem to have he necessary maintenance a RNG library needs to have. Even
> though the problem in question was fixed, it took quite some time for it
> to be detected, and according to other people, it is still has some
> other serious problems left.
>
>>> I hear GCC 4.5 will have improved template performance, since they
>>> switched to O(1) instantiation, instead of O(N).
>>>
>>
>> Ok, that's good to hear. If I recompile with gcc-4.5 then I also need
>> to recompile my whole python stack with 4.5 too (including numpy and
>> scipy etc...)- so that is my motivation to get something working with
>> gcc-4.2.
>
> No, it is not so drastic. There was a C++ ABI change after 4.2 (IIRC),
> but the interface to C libraries (such as python, numpy, etc) should be
> stable. You should only have to recompile the boost libraries. And if
> you do it now with gcc 4.4, it should still be compatible with 4.5.
>
> Cheers,
> Tiago
>
>
> _______________________________________________
> graph-tool mailing list
> graph-tool <at> forked.de
> http://lists.forked.de/mailman/listinfo/graph-tool
>
>
Tiago de Paula Peixoto | 26 Jan 2010 08:51
Picon
Gravatar

Re: building graph-tool under Mac OS X

Hi,

On 01/26/2010 01:38 AM, tcb wrote:
> Hi,
>
> Those changes look good, and fix the configure problems. It seems to
> be compiling away just fine (I'll let you know in a day or so if it
> finishes :) )

Good! I'll make a new release once we know it is working.

> It is unfortunate about the boost random libraries- they seemed to me
> very well designed, and they should be more carefully maintainted. I
> am not so sure the tr1 random libraries are better maintained. Anyway,
> it would only be an issue if we wanted to make a macport using the
> gcc-4.2 compiler (which chokes on tr1::random).

The tr1::random interface was reviewed by the tr1 committee, and will be
part of the upcoming C++ standard. It is now in GCC, and I assume there
as a great deal of responsibility (and interest) in getting it to work
right. So far I haven't seen any problems, and I'm using it constantly
for a variety of projects. Anyway, as soon as tr1 becomes the standard,
there will be no point in using boost::random, or many other boost
libraries (tuple, type_traits, etc), since boost is largely a playground
for libraries that one day might make it to the standard.

Using gcc 4.4 should not be a problem in macports... Apparently you can
choose your own compiler, and it is there on the list:

http://trac.macports.org/wiki/UsingTheRightCompiler

The only problem is that boost (and CGAL) would have to be compiled with
it as well.

Cheers,
Tiago

_______________________________________________
graph-tool mailing list
graph-tool <at> forked.de
http://lists.forked.de/mailman/listinfo/graph-tool

Gmane