Hi all,
I'm trying to compile graph-tool on a macbook with mac os x v10.4.11, but compilation fails as follows:
/opt/local/bin/i386-apple-darwin8.11.1-gcc-4.2.2 -DHAVE_CONFIG_H - I. -I../.. -I. -I.. -I../boost-workaround -DHAVE_CONFIG_H -Wall -I/ opt/local/include/python2.5 -pthread -I/opt/local/include/ boost-1_34_1 -ftemplate-depth-150 -O99 -Wno-unknown-pragmas -MT graph.lo -MD -MP -MF .deps/graph.Tpo -c graph.cc -fno-common -DPIC - o .libs/graph.o graph.cc: In function 'void catch_sig_stop(int)': graph.cc:560: error: 'SIGPWR' was not declared in this scope graph.cc: In member function 'void graph_tool::GraphInterface::InitSignalHandling()': graph.cc:593: error: 'SIGPWR' was not declared in this scope make[3]: *** [graph.lo] Error 1 make[2]: *** [all-recursive] Error 1 make[1]: *** [all-recursive] Error 1 make: *** [all] Error 2
My system is: python v2.5.1 gcc v4.2.2 boost v1.34.1
I'm using the following configure command: sudo ./configure --prefix=/opt/local --with-boost=/opt/local -- disable-visibility CC=/opt/local/bin/i386-apple-darwin8.11.1- gcc-4.2.2 CXX=/opt/local/bin/i386-apple-darwin8.11.1-gcc-4.2.2 PYTHON_VERSION=2.5 LDFLAGS=-L/opt/local/lib/
Any ideas?
Thanks,
Spiros
On 01/20/2008 03:27 PM, Spiros Spirou wrote:
Hi all,
I'm trying to compile graph-tool on a macbook with mac os x v10.4.11, but compilation fails as follows:
[...]
graph.cc:560: error: 'SIGPWR' was not declared in this scope
[...]
Any ideas?
Oops. Looks like SIGPWR is not defined in MacOS X. I've committed a fix for this in the git repository. Please get the newest git version, and see if you have any trouble now.
Thanks for the bug report.
Tiago
On 22 Ιαν 2008, at 2:47 ΜΜ, Tiago de Paula Peixoto wrote:
On 01/20/2008 03:27 PM, Spiros Spirou wrote:
Hi all, I'm trying to compile graph-tool on a macbook with mac os x v10.4.11, but compilation fails as follows:
[...]
graph.cc:560: error: 'SIGPWR' was not declared in this scope
[...]
Any ideas?
Oops. Looks like SIGPWR is not defined in MacOS X. I've committed a fix for this in the git repository. Please get the newest git version, and see if you have any trouble now.
Thanks! This is fixed now, but there's another problem later on. It seems that the linker on mac os x v10.4.11 does not support the '-E' option. Here's the error I get:
/usr/bin/ld: unknown flag: -E
I'm not sure what I need to change to eliminate this option, if possible. Could you please help?
Thanks,
Spiros
On 01/23/2008 01:37 PM, Spiros Spirou wrote:
Thanks! This is fixed now, but there's another problem later on. It seems that the linker on mac os x v10.4.11 does not support the '-E' option. Here's the error I get:
/usr/bin/ld: unknown flag: -E
I'm not sure what I need to change to eliminate this option, if possible. Could you please help?
Do you know what linker is used in MacOS X? Could you please send me the output of ld --version (or the equivalent for this linker)?
Cheers, Tiago
On 23 Ιαν 2008, at 10:18 ΜΜ, Tiago de Paula Peixoto wrote:
On 01/23/2008 01:37 PM, Spiros Spirou wrote:
Thanks! This is fixed now, but there's another problem later on. It seems that the linker on mac os x v10.4.11 does not support the '-E' option. Here's the error I get:
/usr/bin/ld: unknown flag: -E
I'm not sure what I need to change to eliminate this option, if possible. Could you please help?
Do you know what linker is used in MacOS X? Could you please send me the output of ld --version (or the equivalent for this linker)?
Sorry for not sending this earlier. I'm not sure that it helps, but here it is:
spirosspirou$ /usr/bin/ld -v Apple Computer, Inc. version cctools-622.5.obj~13
Is the '-E' option really necessary? Could we just remove it from the LDFLAGS for darwin? (Problem is, I don't know how to do this :) ).
Thanks,
Spiros
On 01/24/2008 09:18 AM, Spiros Spirou wrote:
On 23 Ιαν 2008, at 10:18 ΜΜ, Tiago de Paula Peixoto wrote:
On 01/23/2008 01:37 PM, Spiros Spirou wrote:
Thanks! This is fixed now, but there's another problem later on. It seems that the linker on mac os x v10.4.11 does not support the '-E' option. Here's the error I get:
/usr/bin/ld: unknown flag: -E
I'm not sure what I need to change to eliminate this option, if possible. Could you please help?
Do you know what linker is used in MacOS X? Could you please send me the output of ld --version (or the equivalent for this linker)?
Sorry for not sending this earlier. I'm not sure that it helps, but here it is:
spirosspirou$ /usr/bin/ld -v Apple Computer, Inc. version cctools-622.5.obj~13
Is the '-E' option really necessary? Could we just remove it from the LDFLAGS for darwin? (Problem is, I don't know how to do this :) ).
The behaviour of the '-E' flag in GNU ld is necessary to export all dynamic symbols, which is not done by default. So indeed we need this, since the run_action() functionality, which compiles and loads C++ code from python at run time, needs all symbols to be exported properly. I looked at apple's (darwin) ld manpage, http://www.hmug.org/man/1/ld.php, and at first glance, found no equivalent option. So I'm just going to drop this for any liker that doesn't support the option, and hope it will do what we want by default. The git version already contains this fix. Please tell me if it compiles for you now...
Cheers, Tiago
Hi Tiago,
On 24 Ιαν 2008, at 4:10 ΜΜ, Tiago de Paula Peixoto wrote:
On 01/24/2008 09:18 AM, Spiros Spirou wrote:
On 23 Ιαν 2008, at 10:18 ΜΜ, Tiago de Paula Peixoto wrote:
On 01/23/2008 01:37 PM, Spiros Spirou wrote:
Thanks! This is fixed now, but there's another problem later on. It seems that the linker on mac os x v10.4.11 does not support the '-E' option. Here's the error I get:
/usr/bin/ld: unknown flag: -E
I'm not sure what I need to change to eliminate this option, if possible. Could you please help?
Do you know what linker is used in MacOS X? Could you please send me the output of ld --version (or the equivalent for this linker)?
Sorry for not sending this earlier. I'm not sure that it helps, but here it is: spirosspirou$ /usr/bin/ld -v Apple Computer, Inc. version cctools-622.5.obj~13 Is the '-E' option really necessary? Could we just remove it from the LDFLAGS for darwin? (Problem is, I don't know how to do this :) ).
The behaviour of the '-E' flag in GNU ld is necessary to export all dynamic symbols, which is not done by default. So indeed we need this, since the run_action() functionality, which compiles and loads C++ code from python at run time, needs all symbols to be exported properly. I looked at apple's (darwin) ld manpage, http://www.hmug.org/man/1/ ld.php, and at first glance, found no equivalent option. So I'm just going to drop this for any liker that doesn't support the option, and hope it will do what we want by default. The git version already contains this fix. Please tell me if it compiles for you now...
Thank you for the prompt response! This release got me further, but I've hit another wall that looks scary. Here it is:
vtable for __cxxabiv1::__function_type_info std::range_error::range_error(std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) collect2: ld returned 1 exit status make[3]: *** [libgraph_tool.la] Error 1
Is it that some prototypes do not match? I'm really clueless...
Cheers,
Spiros
On 01/24/2008 04:46 PM, Spiros Spirou wrote:
Hi Tiago,
On 24 Ιαν 2008, at 4:10 ΜΜ, Tiago de Paula Peixoto wrote:
On 01/24/2008 09:18 AM, Spiros Spirou wrote:
On 23 Ιαν 2008, at 10:18 ΜΜ, Tiago de Paula Peixoto wrote:
On 01/23/2008 01:37 PM, Spiros Spirou wrote:
Thanks! This is fixed now, but there's another problem later on. It seems that the linker on mac os x v10.4.11 does not support the '-E' option. Here's the error I get:
/usr/bin/ld: unknown flag: -E
I'm not sure what I need to change to eliminate this option, if possible. Could you please help?
Do you know what linker is used in MacOS X? Could you please send me the output of ld --version (or the equivalent for this linker)?
Sorry for not sending this earlier. I'm not sure that it helps, but here it is: spirosspirou$ /usr/bin/ld -v Apple Computer, Inc. version cctools-622.5.obj~13 Is the '-E' option really necessary? Could we just remove it from the LDFLAGS for darwin? (Problem is, I don't know how to do this :) ).
The behaviour of the '-E' flag in GNU ld is necessary to export all dynamic symbols, which is not done by default. So indeed we need this, since the run_action() functionality, which compiles and loads C++ code from python at run time, needs all symbols to be exported properly. I looked at apple's (darwin) ld manpage, http://www.hmug.org/man/1/ ld.php, and at first glance, found no equivalent option. So I'm just going to drop this for any liker that doesn't support the option, and hope it will do what we want by default. The git version already contains this fix. Please tell me if it compiles for you now...
Thank you for the prompt response! This release got me further, but I've hit another wall that looks scary. Here it is:
vtable for __cxxabiv1::__function_type_info std::range_error::range_error(std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) collect2: ld returned 1 exit status make[3]: *** [libgraph_tool.la] Error 1
Is it that some prototypes do not match? I'm really clueless...
Strange... Could you please send me the full compilation output attached? Also, what version of GCC are you using?
Cheers, Tiago
Hi Tiago,
On 24 Ιαν 2008, at 7:48 ΜΜ, Tiago de Paula Peixoto wrote:
On 01/24/2008 04:46 PM, Spiros Spirou wrote:
Thank you for the prompt response! This release got me further, but I've hit another wall that looks scary. Here it is: vtable for __cxxabiv1::__function_type_info std::range_error::range_error(std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) collect2: ld returned 1 exit status make[3]: *** [libgraph_tool.la] Error 1 Is it that some prototypes do not match? I'm really clueless...
Strange... Could you please send me the full compilation output attached?
Attached.
It seems that the linker has unresolved symbols. I tried configuring the path to libstdc++ ('-L/opt/local/lib/gcc42') in LDFLAG, but I get the same error.
Also, what version of GCC are you using?
4.2.2
Cheers,
Spiros
On 01/25/2008 08:56 AM, Spiros Spirou wrote:
Hi Tiago,
On 24 Ιαν 2008, at 7:48 ΜΜ, Tiago de Paula Peixoto wrote:
On 01/24/2008 04:46 PM, Spiros Spirou wrote:
Thank you for the prompt response! This release got me further, but I've hit another wall that looks scary. Here it is: vtable for __cxxabiv1::__function_type_info std::range_error::range_error(std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) collect2: ld returned 1 exit status make[3]: *** [libgraph_tool.la] Error 1 Is it that some prototypes do not match? I'm really clueless...
Strange... Could you please send me the full compilation output attached?
Attached.
It seems that the linker has unresolved symbols. I tried configuring the path to libstdc++ ('-L/opt/local/lib/gcc42') in LDFLAG, but I get the same error.
The compiler is not linking to the standard C++ library and to the zlib and bzip2 libraries, and all the dynamic symbols are turning up unresolved. libtool was supposed to handle all this... Please try the following link command in the src/graph/ directory, and tell me the result:
/bin/sh ../../libtool --tag=CXX --mode=link /opt/local/bin/i386-apple-darwin8.11.1-gcc-4.2.2 -Wall -I/opt/local/include/python2.5 -pthread -I/opt/local/include/boost-1_34_1 -ftemplate-depth-150 -O99 -Wno-unknown-pragmas -module -avoid-version -export-dynamic -no-undefined -L/opt/local/lib/ -o libgraph_tool.la -rpath /opt/local/lib/python2.5/site-packages/graph_tool graph.lo graph_python_interface.lo graph_properties.lo graph_correlations.lo graph_edge_correlations.lo graph_correlations_combined.lo graph_correlations_neighbours.lo graph_assortativity.lo graph_clustering.lo graph_extended_clustering.lo graph_generation.lo graph_distance.lo graph_distance_sampled.lo graph_reciprocity.lo graph_minimum_spanning_tree.lo graph_community.lo graph_community_network.lo graph_line_graph.lo graph_betweenness.lo graph_rewiring.lo graph_layout.lo graph_io.lo graph_bind.lo graphml.lo read_graphviz_spirit.lo -L/opt/local/lib/python2.5 -lpython2.5 -L/opt/local/lib -lboost_python -lboost _iostreams -lexpat -lz -lbzip2 -lstdc++
Cheers, Tiago
Hi Tiago,
Thanks for the support so far!
On 25 Ιαν 2008, at 5:23 ΜΜ, Tiago de Paula Peixoto wrote:
On 01/25/2008 08:56 AM, Spiros Spirou wrote:
Hi Tiago, On 24 Ιαν 2008, at 7:48 ΜΜ, Tiago de Paula Peixoto wrote:
On 01/24/2008 04:46 PM, Spiros Spirou wrote:
Thank you for the prompt response! This release got me further, but I've hit another wall that looks scary. Here it is: vtable for __cxxabiv1::__function_type_info std::range_error::range_error(std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) collect2: ld returned 1 exit status make[3]: *** [libgraph_tool.la] Error 1 Is it that some prototypes do not match? I'm really clueless...
Strange... Could you please send me the full compilation output attached?
Attached.
It seems that the linker has unresolved symbols. I tried configuring the path to libstdc++ ('-L/opt/local/lib/gcc42') in LDFLAG, but I get the same error.
The compiler is not linking to the standard C++ library and to the zlib and bzip2 libraries, and all the dynamic symbols are turning up unresolved. libtool was supposed to handle all this... Please try the following link command in the src/graph/ directory, and tell me the result:
/bin/sh ../../libtool --tag=CXX --mode=link /opt/local/bin/i386- apple-darwin8.11.1-gcc-4.2.2 -Wall -I/opt/local/include/python2.5 - pthread -I/opt/local/include/boost-1_34_1 -ftemplate-depth-150 - O99 -Wno-unknown-pragmas -module -avoid-version -export-dynamic - no-undefined -L/opt/local/lib/ -o libgraph_tool.la -rpath /opt/ local/lib/python2.5/site-packages/graph_tool graph.lo graph_python_interface.lo graph_properties.lo graph_correlations.lo graph_edge_correlations.lo graph_correlations_combined.lo graph_correlations_neighbours.lo graph_assortativity.lo graph_clustering.lo graph_extended_clustering.lo graph_generation.lo graph_distance.lo graph_distance_sampled.lo graph_reciprocity.lo graph_minimum_spanning_tree.lo graph_community.lo graph_community_network.lo graph_line_graph.lo graph_betweenness.lo graph_rewiring.lo graph_layout.lo graph_io.lo graph_bind.lo graphml.lo read_graphviz_spirit.lo -L/opt/local/lib/ python2.5 -lpython2.5 -L/opt/local/lib -lboost_python -lboost _iostreams -lexpat -lz -lbzip2 -lstdc++
Here it is:
/opt/local/bin/i386-apple-darwin8.11.1-gcc-4.2.2 -o .libs/ libgraph_tool.so -bundle .libs/graph.o .libs/ graph_python_interface.o .libs/graph_properties.o .libs/ graph_correlations.o .libs/graph_edge_correlations.o .libs/ graph_correlations_combined.o .libs/ graph_correlations_neighbours.o .libs/graph_assortativity.o .libs/ graph_clustering.o .libs/graph_extended_clustering.o .libs/ graph_generation.o .libs/graph_distance.o .libs/ graph_distance_sampled.o .libs/graph_reciprocity.o .libs/ graph_minimum_spanning_tree.o .libs/graph_community.o .libs/ graph_community_network.o .libs/graph_line_graph.o .libs/ graph_betweenness.o .libs/graph_rewiring.o .libs/graph_layout.o .libs/ graph_io.o .libs/graph_bind.o .libs/graphml.o .libs/ read_graphviz_spirit.o -L/opt/local/lib/ -L/opt/local/lib/python2.5 - lpython2.5 -L/opt/local/lib -lboost_python -lboost /opt/local/lib/ libexpat.dylib -lz -lbzip2 /opt/local/lib/gcc42/libstdc++.dylib -L/ opt/local/var/macports/build/ _opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_gc c42/work/build/i386-apple-darwin8.11.1/libstdc++-v3/src -L/opt/local/ var/macports/build/ _opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_gc c42/work/build/i386-apple-darwin8.11.1/libstdc++-v3/src/.libs -pthread /usr/bin/ld: warning -L: directory name (/opt/local/var/macports/ build/ _opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_gc c42/work/build/i386-apple-darwin8.11.1/libstdc++-v3/src) does not exist /usr/bin/ld: warning -L: directory name (/opt/local/var/macports/ build/ _opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_gc c42/work/build/i386-apple-darwin8.11.1/libstdc++-v3/src/.libs) does not exist /usr/bin/ld: can't locate file for: -lboost collect2: ld returned 1 exit status
Cheers,
Spiros
On 01/25/2008 03:44 PM, Spiros Spirou wrote:
Hi Tiago,
Thanks for the support so far!
It's quite alright. :-)
/usr/bin/ld: can't locate file for: -lboost collect2: ld returned 1 exit status
I think -lboost_iostreams got broken with a line break in the command line. Could you please try again?
Cheers, Tiago
On 25 Ιαν 2008, at 5:48 ΜΜ, Tiago de Paula Peixoto wrote:
I think -lboost_iostreams got broken with a line break in the command line. Could you please try again?
My mistake. Here's the correct output:
/opt/local/bin/i386-apple-darwin8.11.1-gcc-4.2.2 -o .libs/ libgraph_tool.so -bundle .libs/graph.o .libs/ graph_python_interface.o .libs/graph_properties.o .libs/ graph_correlations.o .libs/graph_edge_correlations.o .libs/ graph_correlations_combined.o .libs/ graph_correlations_neighbours.o .libs/graph_assortativity.o .libs/ graph_clustering.o .libs/graph_extended_clustering.o .libs/ graph_generation.o .libs/graph_distance.o .libs/ graph_distance_sampled.o .libs/graph_reciprocity.o .libs/ graph_minimum_spanning_tree.o .libs/graph_community.o .libs/ graph_community_network.o .libs/graph_line_graph.o .libs/ graph_betweenness.o .libs/graph_rewiring.o .libs/graph_layout.o .libs/ graph_io.o .libs/graph_bind.o .libs/graphml.o .libs/ read_graphviz_spirit.o -L/opt/local/lib/ -L/opt/local/lib/python2.5 - lpython2.5 -L/opt/local/lib -lboost_python -lboost_iostreams /opt/ local/lib/libexpat.dylib -lz -lbzip2 /opt/local/lib/gcc42/libstdc+ +.dylib -L/opt/local/var/macports/build/ _opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_gc c42/work/build/i386-apple-darwin8.11.1/libstdc++-v3/src -L/opt/local/ var/macports/build/ _opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_gc c42/work/build/i386-apple-darwin8.11.1/libstdc++-v3/src/.libs -pthread /usr/bin/ld: warning -L: directory name (/opt/local/var/macports/ build/ _opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_gc c42/work/build/i386-apple-darwin8.11.1/libstdc++-v3/src) does not exist /usr/bin/ld: warning -L: directory name (/opt/local/var/macports/ build/ _opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_gc c42/work/build/i386-apple-darwin8.11.1/libstdc++-v3/src/.libs) does not exist /usr/bin/ld: can't locate file for: -lbzip2 collect2: ld returned 1 exit status
I have something called libbz2 in /opt/local/lib. Is this the bzip2 library?
Cheers,
Spiros
On 01/25/2008 06:48 PM, Spiros Spirou wrote:
I have something called libbz2 in /opt/local/lib. Is this the bzip2 library?
Yes, this is it. Please change -lbzip2 to -lbz2 and try again. Cheers.
On 25 Ιαν 2008, at 10:51 ΜΜ, Tiago de Paula Peixoto wrote:
On 01/25/2008 06:48 PM, Spiros Spirou wrote:
I have something called libbz2 in /opt/local/lib. Is this the bzip2 library?
Yes, this is it. Please change -lbzip2 to -lbz2 and try again. Cheers.
OK, here's what I got:
/opt/local/bin/i386-apple-darwin8.11.1-gcc-4.2.2 -o .libs/ libgraph_tool.so -bundle .libs/graph.o .libs/ graph_python_interface.o .libs/graph_properties.o .libs/ graph_correlations.o .libs/graph_edge_correlations.o .libs/ graph_correlations_combined.o .libs/ graph_correlations_neighbours.o .libs/graph_assortativity.o .libs/ graph_clustering.o .libs/graph_extended_clustering.o .libs/ graph_generation.o .libs/graph_distance.o .libs/ graph_distance_sampled.o .libs/graph_reciprocity.o .libs/ graph_minimum_spanning_tree.o .libs/graph_community.o .libs/ graph_community_network.o .libs/graph_line_graph.o .libs/ graph_betweenness.o .libs/graph_rewiring.o .libs/graph_layout.o .libs/ graph_io.o .libs/graph_bind.o .libs/graphml.o .libs/ read_graphviz_spirit.o -L/opt/local/lib/ -L/opt/local/lib/python2.5 - lpython2.5 -L/opt/local/lib -lboost_python -lboost_iostreams /opt/ local/lib/libexpat.dylib -lz -lbz2 /opt/local/lib/gcc42/libstdc+ +.dylib -L/opt/local/var/macports/build/ _opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_gc c42/work/build/i386-apple-darwin8.11.1/libstdc++-v3/src -L/opt/local/ var/macports/build/ _opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_gc c42/work/build/i386-apple-darwin8.11.1/libstdc++-v3/src/.libs -pthread /usr/bin/ld: warning -L: directory name (/opt/local/var/macports/ build/ _opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_gc c42/work/build/i386-apple-darwin8.11.1/libstdc++-v3/src) does not exist /usr/bin/ld: warning -L: directory name (/opt/local/var/macports/ build/ _opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_gc c42/work/build/i386-apple-darwin8.11.1/libstdc++-v3/src/.libs) does not exist /usr/bin/ld: Undefined symbols: __Unwind_Resume collect2: ld returned 1 exit status
S.
On 01/27/2008 08:28 AM, Spiros Spirou wrote:
OK, here's what I got:
/opt/local/bin/i386-apple-darwin8.11.1-gcc-4.2.2 -o .libs/
(...)
/usr/bin/ld: Undefined symbols: __Unwind_Resume collect2: ld returned 1 exit status
It just occurred to me that the gcc binary is being used to link the library, not g++! That's probably the reason of all these undefined references... In your first message, I saw you ran configure with CXX=/opt/local/bin/i386-apple-darwin8.11.1-gcc-4.2.2. This is incorrect. You needed to do something like CXX=/opt/local/bin/i386-apple-darwin8.11.1-g++-4.2.2, assuming that's what g++ is called on your system. Please try a whole build from scratch, using g++ this time, and see if you still encounter any problems.
Cheers, Tiago
Hi Tiago,
On 27 Ιαν 2008, at 7:41 ΜΜ, Tiago de Paula Peixoto wrote:
It just occurred to me that the gcc binary is being used to link the library, not g++! That's probably the reason of all these undefined references... In your first message, I saw you ran configure with CXX=/opt/local/bin/i386-apple-darwin8.11.1-gcc-4.2.2. This is incorrect. You needed to do something like CXX=/opt/local/bin/i386-apple-darwin8.11.1-g++-4.2.2, assuming that's what g++ is called on your system. Please try a whole build from scratch, using g++ this time, and see if you still encounter any problems.
I thought that gcc is just the front-end to the compilers underneath. Thanks for your patience so far...
I did what you suggested, but I still get undefined symbols, although different ones. Strangely, these seem to be related to libbz2, which is in /opt/local/lib. Here's the output:
/bin/sh ../../libtool --tag=CXX --mode=compile /opt/local/bin/i386- apple-darwin8.11.1-g++-mp-4.2 -DHAVE_CONFIG_H -I. -I../.. -I. -I.. - I../boost-workaround -DHAVE_CONFIG_H -Wall -I/opt/local/include/ python2.5 -pthread -I/opt/local/include/boost-1_34_1 -ftemplate- depth-150 -O99 -Wno-unknown-pragmas -MT read_graphviz_spirit.lo -MD -MP -MF .deps/read_graphviz_spirit.Tpo -c -o read_graphviz_spirit.lo read_graphviz_spirit.cpp /opt/local/bin/i386-apple-darwin8.11.1-g++-mp-4.2 -DHAVE_CONFIG_H - I. -I../.. -I. -I.. -I../boost-workaround -DHAVE_CONFIG_H -Wall -I/ opt/local/include/python2.5 -pthread -I/opt/local/include/ boost-1_34_1 -ftemplate-depth-150 -O99 -Wno-unknown-pragmas -MT read_graphviz_spirit.lo -MD -MP -MF .deps/read_graphviz_spirit.Tpo -c read_graphviz_spirit.cpp -fno-common -DPIC -o .libs/ read_graphviz_spirit.o mv -f .deps/read_graphviz_spirit.Tpo .deps/read_graphviz_spirit.Plo /bin/sh ../../libtool --tag=CXX --mode=link /opt/local/bin/i386- apple-darwin8.11.1-g++-mp-4.2 -Wall -I/opt/local/include/python2.5 - pthread -I/opt/local/include/boost-1_34_1 -ftemplate-depth-150 -O99 -Wno-unknown-pragmas -module -avoid-version -export-dynamic -no- undefined -L/opt/local/lib/ -L/opt/local/lib/gcc42 -o libgraph_tool.la -rpath /opt/local/lib/python2.5/site-packages/ graph_tool graph.lo graph_python_interface.lo graph_properties.lo graph_correlations.lo graph_edge_correlations.lo graph_correlations_combined.lo graph_correlations_neighbours.lo graph_assortativity.lo graph_clustering.lo graph_extended_clustering.lo graph_generation.lo graph_distance.lo graph_distance_sampled.lo graph_reciprocity.lo graph_minimum_spanning_tree.lo graph_community.lo graph_community_network.lo graph_line_graph.lo graph_betweenness.lo graph_rewiring.lo graph_layout.lo graph_io.lo graph_bind.lo graphml.lo read_graphviz_spirit.lo -L/opt/local/lib/python2.5 - lpython2.5 -L/opt/local/lib -lboost_python -lboost_iostreams -lexpat /opt/local/bin/i386-apple-darwin8.11.1-g++-mp-4.2 -o .libs/ libgraph_tool.so -bundle .libs/graph.o .libs/ graph_python_interface.o .libs/graph_properties.o .libs/ graph_correlations.o .libs/graph_edge_correlations.o .libs/ graph_correlations_combined.o .libs/ graph_correlations_neighbours.o .libs/graph_assortativity.o .libs/ graph_clustering.o .libs/graph_extended_clustering.o .libs/ graph_generation.o .libs/graph_distance.o .libs/ graph_distance_sampled.o .libs/graph_reciprocity.o .libs/ graph_minimum_spanning_tree.o .libs/graph_community.o .libs/ graph_community_network.o .libs/graph_line_graph.o .libs/ graph_betweenness.o .libs/graph_rewiring.o .libs/graph_layout.o .libs/ graph_io.o .libs/graph_bind.o .libs/graphml.o .libs/ read_graphviz_spirit.o -L/opt/local/lib/ -L/opt/local/lib/gcc42 -L/ opt/local/lib/python2.5 -lpython2.5 -L/opt/local/lib -lboost_python - lboost_iostreams /opt/local/lib/libexpat.dylib -pthread /usr/bin/ld: Undefined symbols: _crc32 _deflate _deflateEnd _deflateInit2_ _deflateReset _inflate _inflateEnd _inflateInit2_ _inflateReset _BZ2_bzCompress _BZ2_bzCompressEnd _BZ2_bzCompressInit _BZ2_bzDecompress _BZ2_bzDecompressEnd _BZ2_bzDecompressInit collect2: ld returned 1 exit status make[3]: *** [libgraph_tool.la] Error 1 make[2]: *** [all-recursive] Error 1 make[1]: *** [all-recursive] Error 1 make: *** [all] Error 2
Thanks,
Spiros
On 01/28/2008 01:30 PM, Spiros Spirou wrote:
Hi Tiago,
On 27 Ιαν 2008, at 7:41 ΜΜ, Tiago de Paula Peixoto wrote:
It just occurred to me that the gcc binary is being used to link the library, not g++! That's probably the reason of all these undefined references... In your first message, I saw you ran configure with CXX=/opt/local/bin/i386-apple-darwin8.11.1-gcc-4.2.2. This is incorrect. You needed to do something like CXX=/opt/local/bin/i386-apple-darwin8.11.1-g++-4.2.2, assuming that's what g++ is called on your system. Please try a whole build from scratch, using g++ this time, and see if you still encounter any problems.
I thought that gcc is just the front-end to the compilers underneath. Thanks for your patience so far...
I did what you suggested, but I still get undefined symbols, although different ones. Strangely, these seem to be related to libbz2, which is in /opt/local/lib. Here's the output:
Try the link with -lbz2 and -lz. You can set LDFLAGS to "-lbz2 -lz" when issuing configure. I don't know why it is trying to link to those libraries directly, since graph_tool uses them only through boost_iostreams, and we're making a dynamic library. I suspect this must be related either to the way things are linked in MacOS X, or maybe how things are installed on your system, I'm not sure. If this works, I'll add "-lbz2 -lz" to graph_tool build by default, since it doesn't really hurt.
Cheers, Tiago
Hi Tiago,
On 28 Ιαν 2008, at 9:11 ΜΜ, Tiago de Paula Peixoto wrote:
Try the link with -lbz2 and -lz. You can set LDFLAGS to "-lbz2 -lz" when issuing configure. I don't know why it is trying to link to those libraries directly, since graph_tool uses them only through boost_iostreams, and we're making a dynamic library. I suspect this must be related either to the way things are linked in MacOS X, or maybe how things are installed on your system, I'm not sure. If this works, I'll add "-lbz2 -lz" to graph_tool build by default, since it doesn't really hurt.
This looked better:
(cd .libs && rm -f libgraph_tool.la && ln -s ../libgraph_tool.la libgraph_tool.la) Making all in graph_tool make[3]: Nothing to be done for `all'. Making all in . make[3]: Nothing to be done for `all-am'. make[2]: Nothing to be done for `all-am'.
But, when I did 'graph-tool --help', here's what I got:
File "/opt/local/bin/graph-tool", line 128 return "|".join(metavars) if len(metavars) > 0 else None ^ SyntaxError: invalid syntax
Cheers,
S.
On 01/29/2008 02:02 PM, Spiros Spirou wrote:
Hi Tiago,
On 28 Ιαν 2008, at 9:11 ΜΜ, Tiago de Paula Peixoto wrote:
Try the link with -lbz2 and -lz. You can set LDFLAGS to "-lbz2 -lz" when issuing configure. I don't know why it is trying to link to those libraries directly, since graph_tool uses them only through boost_iostreams, and we're making a dynamic library. I suspect this must be related either to the way things are linked in MacOS X, or maybe how things are installed on your system, I'm not sure. If this works, I'll add "-lbz2 -lz" to graph_tool build by default, since it doesn't really hurt.
This looked better:
(cd .libs && rm -f libgraph_tool.la && ln -s ../libgraph_tool.la libgraph_tool.la) Making all in graph_tool make[3]: Nothing to be done for `all'. Making all in . make[3]: Nothing to be done for `all-am'. make[2]: Nothing to be done for `all-am'.
But, when I did 'graph-tool --help', here's what I got:
File "/opt/local/bin/graph-tool", line 128 return "|".join(metavars) if len(metavars) > 0 else None ^ SyntaxError: invalid syntax
Are you sure you are using python 2.5? What is the result of 'python --version'?
Cheers, Tiago
Hi Tiago,
On 29 Ιαν 2008, at 7:48 ΜΜ, Tiago de Paula Peixoto wrote:
On 01/29/2008 02:02 PM, Spiros Spirou wrote:
Hi Tiago, On 28 Ιαν 2008, at 9:11 ΜΜ, Tiago de Paula Peixoto wrote:
Try the link with -lbz2 and -lz. You can set LDFLAGS to "-lbz2 -lz" when issuing configure. I don't know why it is trying to link to those libraries directly, since graph_tool uses them only through boost_iostreams, and we're making a dynamic library. I suspect this must be related either to the way things are linked in MacOS X, or maybe how things are installed on your system, I'm not sure. If this works, I'll add "-lbz2 -lz" to graph_tool build by default, since it doesn't really hurt.
This looked better: (cd .libs && rm -f libgraph_tool.la && ln -s ../libgraph_tool.la libgraph_tool.la) Making all in graph_tool make[3]: Nothing to be done for `all'. Making all in . make[3]: Nothing to be done for `all-am'. make[2]: Nothing to be done for `all-am'. But, when I did 'graph-tool --help', here's what I got: File "/opt/local/bin/graph-tool", line 128 return "|".join(metavars) if len(metavars) > 0 else None ^ SyntaxError: invalid syntax
Are you sure you are using python 2.5? What is the result of 'python --version'?
'python -V' gives 'Python 2.3.5'. 'which python' gives '/usr/bin/ python', which is a symbolic link to '/usr/bin/python2.3'.
The version I'd like to use is '/opt/local/bin/python2.5'. That's why in configure options I set 'PYTHON_VERSION=2.5'. According to 'configure --help', "This string will be appended to the Python interpreter canonical name.". If it did that and called 'python2.5' it would execute the desired version, because 'opt/local/bin/' in in PATH earlier than '/usr/bin/'.
Anyhow, I changed the '/usr/bin/python' symbolic link to point to '/ opt/local/bin/python2.5' and here's what I got:
/opt/local/lib/python2.5/site-packages/graph_tool/__init__.py:40: RuntimeWarning: Python C API version mismatch for module libgraph_tool: This Python has API version 1013, module libgraph_tool has version 1012. import libgraph_tool Traceback (most recent call last): File "/opt/local/bin/graph-tool", line 19, in <module> from graph_tool import * File "/opt/local/lib/python2.5/site-packages/graph_tool/ __init__.py", line 45, in <module> import os, os.path, re, struct, fcntl, termios, gzip, bz2, string,\ File "/opt/local/lib/python2.5/gzip.py", line 9, in <module> import zlib ImportError: No module named zlib
I'm attaching config.log, which in my inexperienced eyes looks to be using python2.5 in /opt/local.
Cheers,
Spiros
On 01/30/2008 08:55 AM, Spiros Spirou wrote:
But, when I did 'graph-tool --help', here's what I got: File "/opt/local/bin/graph-tool", line 128 return "|".join(metavars) if len(metavars) > 0 else None ^ SyntaxError: invalid syntax
Are you sure you are using python 2.5? What is the result of 'python --version'?
'python -V' gives 'Python 2.3.5'. 'which python' gives '/usr/bin/python', which is a symbolic link to '/usr/bin/python2.3'.
The version I'd like to use is '/opt/local/bin/python2.5'. That's why in configure options I set 'PYTHON_VERSION=2.5'. According to 'configure --help', "This string will be appended to the Python interpreter canonical name.". If it did that and called 'python2.5' it would execute the desired version, because 'opt/local/bin/' in in PATH earlier than '/usr/bin/'.
This is valid only for the build process, so that the module gets installed in the correct place. However, all python scripts call only "python" (you can check this for other python scripts in your system), otherwise scripts would be tied to a particular python version. Of course, you could also run 'python2.5 /opt/local/bin/graph-tool' to call it by hand with the correct python version.
Anyhow, I changed the '/usr/bin/python' symbolic link to point to '/opt/local/bin/python2.5' and here's what I got:
/opt/local/lib/python2.5/site-packages/graph_tool/__init__.py:40: RuntimeWarning: Python C API version mismatch for module libgraph_tool: This Python has API version 1013, module libgraph_tool has version 1012.
It looks like the libpython you have installed on your system belongs to a different version than graph_tool was compiled. You can check which version was used by looking at the libgraph_tool.so module:
ldd /opt/local/lib/python2.5/site-packages/graph_tool/libgraph_tool.so
(I assume this is the correct path on your system...)
import libgraph_tool Traceback (most recent call last): File "/opt/local/bin/graph-tool", line 19, in <module> from graph_tool import * File "/opt/local/lib/python2.5/site-packages/graph_tool/__init__.py", line 45, in <module> import os, os.path, re, struct, fcntl, termios, gzip, bz2, string,\ File "/opt/local/lib/python2.5/gzip.py", line 9, in <module> import zlib ImportError: No module named zlib
Notice this an error from the standard python module "gzip", which tries to load the "zlib" module and fails. This module should be there, since it is also a standard python module. It looks like there's something wrong with your python installation.
I'm attaching config.log, which in my inexperienced eyes looks to be using python2.5 in /opt/local.
Yes, it uses that to install the module in the correct place, and to link to the correct python library. But it has nothing to do with the runtime environment... If you have python 2.3 installed as default, it is going to use that.
Cheers, Tiago
Hi Tiago,
On 31 Ιαν 2008, at 12:01 ΠΜ, Tiago de Paula Peixoto wrote:
It looks like there's something wrong with your python installation.
You are right, of course. Python on Mac OS X is supposed to be installed as a 'framework'. I'll pretend to understand what this means by saying it's some kind of special library. So, I did the framework installation of Python. Now it looks like that you can no longer link to Python with '-lpython2.5' but you need to use '- framework Python' instead. Here's what the 'ld' man says:
" -framework name[,suffix] Specifies a framework to link against. Frameworks are dynamic shared libraries, but they are stored in different locations, and therefore must be searched for differently. When this option is specified, ld searches for framework `name.framework/name' first in any directories specified with the -F option, then in the standard framework directories /Library/ Frameworks, /Net- work/Library/Frameworks, and /System/Library/ Frameworks. The placement of the -framework option is significant, as it deter- mines when and how the framework is searched. If the optional suffix is specified the framework is first searched for the name with the suffix and then without. "
As you can understand, ./configure fails now with:
checking for Python library path... -L/Library/Frameworks/ Python.framework/Versions/2.5/lib/python2.5 -lpython2.5 checking for Python site-packages path... /Library/Frameworks/ Python.framework/Versions/2.5/lib/python2.5/site-packages checking python extra libraries... -ldl checking python extra linking flags... -u _PyMac_Error Python.framework/Versions/2.5/Python checking consistency of all components of python development environment... no configure: error: Could not link test program to Python. Maybe the main Python library has been installed in some non-standard library path. If so, pass it to configure, via the LDFLAGS environment variable. Example: ./configure LDFLAGS="-L/usr/non-standard-path/python/lib"
======================================================================== ==== ERROR! You probably have to install the development version of the Python package for your distribution. The exact name of this package varies among them.
======================================================================== ====
Could you please tell me how/where to make the change so that it uses -framework instead of -l?
Cheers,
Spiros
Spiros Spirou spiros.spirou@ucl.ac.uk writes:
Hi Tiago,
On 31 Ιαν 2008, at 12:01 ΠΜ, Tiago de Paula Peixoto wrote:
It looks like there's something wrong with your python installation.
You are right, of course. Python on Mac OS X is supposed to be installed as a 'framework'. I'll pretend to understand what this means by saying it's some kind of special library. So, I did the framework installation of Python. Now it looks like that you can no longer link to Python with '-lpython2.5' but you need to use '- framework Python' instead. Here's what the 'ld' man says:
[...]
Could you please tell me how/where to make the change so that it uses -framework instead of -l?
Did you try setting LDFLAGS to "-framework Python"? The autotools framework uses libtool to link everything together. There should be more general steps to compile things for MacOS, though I'm not familiar with them. Did you check FINK?
Best regards, Tiago
Hi Tiago,
On 07 Φεβ 2008, at 2:49 ΠΜ, Tiago de Paula Peixoto wrote:
Spiros Spirou spiros.spirou@ucl.ac.uk writes:
Could you please tell me how/where to make the change so that it uses -framework instead of -l?
Did you try setting LDFLAGS to "-framework Python"?
Yes I did, but ./configure still fails when it tries to test linking to the python lib.
The autotools framework uses libtool to link everything together. There should be more general steps to compile things for MacOS, though I'm not familiar with them. Did you check FINK?
Will do.
Thanks,
Spiros
Spiros-
Have you tried installing Linux on a spare box? I hear it fixes most of these endless and pesky issues on OS X. I've spent far more time than I'd like to recall trying to get various FLOSS tools and libraries I use to work on OS X, and I have no plans to head back to the platform anytime soon.
Cheers, Cyrus
On Thu, 2008-02-07 at 10:39 +0200, Spiros Spirou wrote:
Hi Tiago,
On 07 Φεβ 2008, at 2:49 ΠΜ, Tiago de Paula Peixoto wrote:
Spiros Spirou spiros.spirou@ucl.ac.uk writes:
Could you please tell me how/where to make the change so that it uses -framework instead of -l?
Did you try setting LDFLAGS to "-framework Python"?
Yes I did, but ./configure still fails when it tries to test linking to the python lib.
The autotools framework uses libtool to link everything together. There should be more general steps to compile things for MacOS, though I'm not familiar with them. Did you check FINK?
Will do.
Thanks,
Spiros
graph-tool mailing list graph-tool@forked.de http://lists.forked.de/mailman/listinfo/graph-tool
Cyrus Hall hallc@lu.unisi.ch writes:
Spiros-
Have you tried installing Linux on a spare box? I hear it fixes most of these endless and pesky issues on OS X. I've spent far more time than I'd like to recall trying to get various FLOSS tools and libraries I use to work on OS X, and I have no plans to head back to the platform anytime soon.
GNU/Linux can easily be installed on a MacBook as well, side by side with MacOS X. In fact I that's exactly what I have.
However, in princible, being MacOS X a darwin/bsd system in disguise, it should be possible to install most stuff on it. If I'm not mistaken, that's what the whole FINK project is about. But despite having it on my machine, I have no experience installing anything on MacOS X, except for firmware upgrades, and I'm a bit short on time to experiment. Let's see what Spiros is able to accomplish. :-)
Cheers, Tiago
Hi Tiago,
On 07 Φεβ 2008, at 3:20 ΜΜ, Tiago de Paula Peixoto wrote:
Let's see what Spiros is able to accomplish. :-)
I'm afraid that my abilities on the command line are severely limited. If the linbox case ends up too awkward though (moving files around), I'll try harder on MacOS.
Thanks for the support guys.
Cheers,
Spiros
Hi Cyrus,
On 07 Φεβ 2008, at 1:12 ΜΜ, Cyrus Hall wrote:
Have you tried installing Linux on a spare box? I hear it fixes most of these endless and pesky issues on OS X. I've spent far more time than I'd like to recall trying to get various FLOSS tools and libraries I use to work on OS X, and I have no plans to head back to the platform anytime soon.
I'm generally happy with MacOS, but in this case I think you read my mind. I'll try on a linux box.
Cheers,
Spiros
-
Cyrus Hall -
Spiros Spirou -
Tiago de Paula Peixoto