py27-graph-tool @2.2.15 won't build

[anthony.bak@…]

When I try to install py27-graph-tool it does not build. Error log attached.

Some system info:

Max OSX Lion

XCode:
 Version:	4.1 (4B110)
  Location:	/Developer
  Applications:
  Xcode:	4.1 (516)
  Instruments:	4.1 (4138)
  Dashcode:	3.0.2 (336)
  SDKs:
  Mac OS X:
  10.6:	(10J567)
  10.7:	(11A511a)
  iPhone OS:
  4.3:	(8H7)
  iPhone Simulator:
  4.3:	(8H7)

[mamoll (Mark Moll)]

I can reproduce the bug, but don't know what the solution is.

[mamoll (Mark Moll)]

Possible fix committed in r92087. I just switched to the latest git version. Once 2.2.16 is released, we'll switch back to official releases.

[count0 (Tiago de Paula Peixoto)]

Replying to mmoll@…:

Possible fix committed in r92087. I just switched to the latest git version. Once 2.2.16 is released, we'll switch back to official releases.

Version 2.2.16.2 is there, and it should build OK.

I think it would be nice to have a "-devel" version of the port, which always points to the git version. What do you think?

[mamoll (Mark Moll)]

Even a git version would have to fixed to a particular change set. Otherwise, it's extremely tricky to resolve bug reports. We wouldn't know which change set a user would have installed. Of course, we can add a -devel port for a particular change set, but this is typically done only if the non-devel version is broken for some architectures or if there are some critical new features in the devel port. I will check if 2.2.16.2 builds and runs on Lion.

[mamoll (Mark Moll)]

2.2.16.2 doesn't build with clang 3.1svn (Xcode 4.3) or llvm-gcc-4.2 (the two compilers that most people on OS X have). I have attached the build log for clang. Tiago, is this easy to fix? If not, what compilers are officially supported?

[count0 (Tiago de Paula Peixoto)]

This is not easy to support clang or llmv-gcc. You must use GCC. The latest FSF GCC would be ideal, but the last time I tried it produced strange segfaults. Apple's GCC 4.2 should work.

[mamoll (Mark Moll)]

The attached Portfile seems to build and install everything. I compiled everything with gcc46. However, the code crashes on a simple example I pulled from the graph-tool web site:

#!/bin/env python

import graph_tool.all as gt
from numpy import *
from numpy.random import seed, zipf
seed(43)
g = gt.price_network(1500)
deg = g.degree_property_map("in")
deg.a = 4 * (sqrt(deg.a) * 0.5 + 0.4)
ebet = gt.betweenness(g)[1]
ebet.a /= ebet.a.max() / 10.
eorder = ebet.copy()
eorder.a *= -1
pos = gt.sfdp_layout(g)
control = g.new_edge_property("vector<double>")
for e in g.edges():
    d = sqrt(sum((pos[e.source()].a - pos[e.target()].a) ** 2)) / 5
    control[e] = [0.3, d, 0.7, d]
gt.graph_draw(g, pos=pos, vertex_size=deg, vertex_fill_color=deg, vorder=deg,
              edge_color=ebet, eorder=eorder, edge_pen_width=ebet,
              edge_control_points=control, # some curvy edges
              output="graph-draw.pdf")

I get this stack trace:

#0  0x00007fff9ab656c0 in malloc_error_break ()
#1  0x00007fff9ab65805 in free ()
#2  0x0000000102c76d5b in boost::any::holder<std::string>::~holder ()

[count0 (Tiago de Paula Peixoto)]

This is not bug in either graph-tool or boost, this is simply caused by some weirdness with the standard FSF GCC in MacOS + Macports. You should be able to compile with apple's gcc 4.2, and the code will not crash. It is a real pity that the standard GCC somehow does not work well on this platform... I'd much rather be able to use it than apple's version.

[mamoll (Mark Moll)]

How do you know that the problem is with clang and FSF gcc? As far as I know these are fairly standards-compliant compilers. I tried to compile with the apple-gcc-4.2 compile and that fails spectacularly, producing a log file close to one 1GB (luckily very compressible), that I have attached. Below are some of the error messages I get:

:info:build graph_sfdp.hh:131: error: call of overloaded 'pow(int, int)' is ambiguous
:info:build graph_sfdp.hh:131: error: call of overloaded 'pow(long long int, int)' is ambiguous
:info:build graph_sfdp.hh:314: error: no matching function for call to 'get(boost::tuples::tuple<std::vector<double, std::allocator<double> >, double, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type>&)'
:info:build graph_sfdp.hh:314: error: no matching function for call to 'get(boost::tuples::tuple<std::vector<double, std::allocator<double> >, int, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type>&)'
:info:build graph_sfdp.hh:314: error: no matching function for call to 'get(boost::tuples::tuple<std::vector<double, std::allocator<double> >, long double, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type>&)'

[count0 (Tiago de Paula Peixoto)]

I'll fix the problem with apple-gcc; it is a very simple issue.

Regarding the crash with with FSF GCC, just take a look at the stack trace. It comes from within the free function, within the boost::any code. I was able to reproduce these bugs with very simple boost::python examples from the boost documentation. It is very unlikely these are actual bugs in the libraries, since these examples run flawlessly in other architectures and compilers.

I haven't investigated in detail why clang does not compile graph_tool, but I do use some specific functions from GCC in order to demangle C++ symbol names for debugging purposes, and this will definitely not work with clang. But I will investigate clang as an option, since apple-gcc will probably be deprecated at some point.

[mamoll (Mark Moll)]

Thanks. Let me know when you have an update. Apple gcc 4.2 has already been deprecated for a number of OS X releases. It is still available as a port in MacPorts, but this means that when someone wants to use graph-tool, they first have to download and install an additional compiler. It's mostly ports for old, unmaintained code that require this compiler, so that's why I am kind of surprised that bleeding edge C++ code compiles better with apple-gcc-4.2 than regular gcc 4.x (x=4,5,6,7) or clang 3.1. If you can wrap your debugging code in some #ifdef's, perhaps that would make it more portable? Do you have any idea if llvm-gcc-4.2 would work?

[count0 (Tiago de Paula Peixoto)]

Please try now with the python3 branch of the git repository (it is also backwards compatible with python 2), using clang. I've made the necessary adjustments, and it compiles and runs with clang 3.1 without a problem in my GNU/Linux machine. It was much more straightforward than I had expected...

I hope it works, since I will be glad in ditching apple-gcc.

[mamoll (Mark Moll)]

Still doesn't compile. I have attached the new Portfile (Portfile2) and log file (main3.log.gz). These are the errors I see:

:info:build ./graph_sfdp.hh:378:37: error: call to 'pow' is ambiguous
:info:build ./graph_sfdp.hh:131:14: error: call to 'pow' is ambiguous
:info:build ./graph_sfdp.hh:131:14: error: call to 'pow' is ambiguous
:info:build ./graph_sfdp.hh:131:14: error: call to 'pow' is ambiguous
:info:build graph_sfdp.cc:253:22: error: no matching function for call to 'dist'

This is with change set ed7b3bc99df5440978bd258c70171cec806f5534 of graph-tool.

[count0 (Tiago de Paula Peixoto)]

Did you use clang3.1?

I've commited some fixes to the git version, which hopefuly should fix these errors. Please tell me if there is still any issues left.

[mamoll (Mark Moll)]

Yes, I'm using clang3.1. With the last revision I get these errors now:

:info:build ./graph_sfdp.hh:131:14: error: call to 'pow' is ambiguous
:info:build ./graph_sfdp.hh:147:16: error: no matching function for call to 'dist'
:info:build ./graph_sfdp.hh:364:31: error: no matching function for call to 'f_a'
:info:build ./graph_sfdp.hh:379:31: error: no matching function for call to 'f_a'
:info:build ./graph_sfdp.hh:364:31: error: no matching function for call to 'f_a'
:info:build ./graph_sfdp.hh:379:31: error: no matching function for call to 'f_a'
:info:build ./graph_sfdp.hh:364:31: error: no matching function for call to 'f_a'
:info:build ./graph_sfdp.hh:379:31: error: no matching function for call to 'f_a'
:info:build ./graph_sfdp.hh:364:31: error: no matching function for call to 'f_a'
:info:build ./graph_sfdp.hh:379:31: error: no matching function for call to 'f_a'
:info:build ./graph_sfdp.hh:364:31: error: no matching function for call to 'f_a'
:info:build ./graph_sfdp.hh:379:31: error: no matching function for call to 'f_a'
:info:build ./graph_sfdp.hh:364:31: error: no matching function for call to 'f_a'
:info:build ./graph_sfdp.hh:379:31: error: no matching function for call to 'f_a'
:info:build ./graph_sfdp.hh:364:31: error: no matching function for call to 'f_a'
:info:build ./graph_sfdp.hh:379:31: error: no matching function for call to 'f_a'
:info:build ./graph_sfdp.hh:364:31: error: no matching function for call to 'f_a'
:info:build ./graph_sfdp.hh:379:31: error: no matching function for call to 'f_a'
:info:build ./graph_sfdp.hh:364:31: error: no matching function for call to 'f_a'
:info:build fatal error: too many errors emitted, stopping now [-ferror-limit=]
:info:build 20 errors generated.

[count0 (Tiago de Paula Peixoto)]

Just to avoid some repetitive trial and error, could you replace by hand the line ./graph_sfdp.hh:131 by

    r += pow(double(p1[i] - p2[i]), 2);

And see if it stops complaining? The remaining errors seem to be due to the correct pow function not being found in this spot.

[mamoll (Mark Moll)]

Your change didn't work, but this did:

r += pow((double)(p1[i] - p2[i]), 2.);

[mamoll (Mark Moll)]

I spoke too soon. The code compiles with that change, but something must have changed in the linking because now I get this runtime error:

> python gtdemo.py 2>&1 |c++filt
Traceback (most recent call last):
  File "gtdemo.py", line 3, in <module>
    import graph_tool.all as gt
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/graph_tool/__init__.py", line 95, in <module>
    dl_import("from . import libgraph_tool_core as libcore")
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/graph_tool/dl_import.py", line 57, in dl_import
    exec(import_expr, local_dict, global_dict)
  File "<string>", line 1, in <module>
ImportError: dlopen(/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/graph_tool/libgraph_tool_core.so, 8): Symbol not found: graph_tool::get_type_name<boost::mpl::vector<unsigned char, int, long long, double, long double, std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::vector<unsigned char, std::allocator<unsigned char> >, std::vector<int, std::allocator<int> >, std::vector<long long, std::allocator<long long> >, std::vector<double, std::allocator<double> >, std::vector<long double, std::allocator<long double> >, std::vector<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::basic_string<char, std::char_traits<char>, std::allocator<char> > > >, boost::python::api::object, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na>, boost::mpl::vector<unsigned char, int, long long, double, long double, std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::vector<unsigned char, std::allocator<unsigned char> >, std::vector<int, std::allocator<int> >, std::vector<long long, std::allocator<long long> >, std::vector<double, std::allocator<double> >, std::vector<long double, std::allocator<long double> >, std::vector<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::basic_string<char, std::char_traits<char>, std::allocator<char> > > >, boost::python::api::object, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na> >::_all_names
  Referenced from: /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/graph_tool/libgraph_tool_core.so
  Expected in: flat namespace
 in /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/graph_tool/libgraph_tool_core.so

[count0 (Tiago de Paula Peixoto)]

Yes, this last bug I also noticed. I have fixed both issues now in the git version. Please checkout the master branch (the python3 branch has now been merged), and try once more. Hopefuly this is the last time.

[mamoll (Mark Moll)]

That works. The gtk3 / cairo bindings still won't work, because (a) gtk3 is broken (see #34530) and (b) introspection is not enabled on a lot of the relevant dependencies (see #33877). Nevertheless, graph-tool is still usable without it, so I'll commit the Portfile I have right now, which fetches that git version. It'd be preferable if you could make another release, so that we can just download a tar ball instead of having to use git.

[count0 (Tiago de Paula Peixoto)]

Thanks. Yes, I'll make another release soon.

[count0 (Tiago de Paula Peixoto)]

I'm planning to roll out a release. Would you care to test if the current git HEAD still works fine? Thanks.

[mamoll (Mark Moll)]

Done. Everything still compiles. The code in comment:7 still runs.

[mamoll (Mark Moll)]

Replying to mmoll@…:

Done. Everything still compiles. The code in ​https://trac.macports.org/ticket/33641#comment:7 still runs.

However, if I remove the `output="graph-draw.pdf"' from the example, I get this error:

{{{Traceback (most recent call last):

File "/Users/mmoll/gtdemo.py", line 21, in <module>

edge_control_points=control)

File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/graph_tool/draw/cairo_draw.py", line 622, in graph_draw

return interactive_window(g, pos, vprops, eprops, vorder, eorder,

NameError: global name 'interactive_window' is not defined}}}

Even with the original example I need to set DYLD_FALLBACK_LIBRARY_PATH=/opt/local/lib, but this could be a problem with a dependency (py27-gobject3?).

[count0 (Tiago de Paula Peixoto)]

Replying to mmoll@…:

Done. Everything still compiles. The code in comment:7 still runs.

Version 2.2.17 has now been released.

[count0 (Tiago de Paula Peixoto)]

Replying to mmoll@…:

Replying to mmoll@…:

Done. Everything still compiles. The code in comment:7 still runs.

However, if I remove the `output="graph-draw.pdf"' from the example, I get this error:

Traceback (most recent call last):
  File "/Users/mmoll/gtdemo.py", line 21, in <module>
    edge_control_points=control)
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/graph_tool/draw/cairo_draw.py", line 622, in graph_draw
    return interactive_window(g, pos, vprops, eprops, vorder, eorder,
NameError: global name 'interactive_window' is not defined

Even with the original example I need to set DYLD_FALLBACK_LIBRARY_PATH=/opt/local/lib, but this could be a problem with a dependency (py27-gobject3?).

The graph_draw() function should not be relied upon, if gobject, pycairo and gtk are not working properly. Instead, you may use the graphviz_draw() function, which is the same as in the older versions.

[mamoll (Mark Moll)]

Replying to tiago@…:

Replying to mmoll@…:

Replying to mmoll@…:

Done. Everything still compiles. The code in comment:7 still runs.

However, if I remove the `output="graph-draw.pdf"' from the example, I get this error:

Traceback (most recent call last):
  File "/Users/mmoll/gtdemo.py", line 21, in <module>
    edge_control_points=control)
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/graph_tool/draw/cairo_draw.py", line 622, in graph_draw
    return interactive_window(g, pos, vprops, eprops, vorder, eorder,
NameError: global name 'interactive_window' is not defined

Even with the original example I need to set DYLD_FALLBACK_LIBRARY_PATH=/opt/local/lib, but this could be a problem with a dependency (py27-gobject3?).

The graph_draw() function should not be relied upon, if gobject, pycairo and gtk are not working properly. Instead, you may use the graphviz_draw() function, which is the same as in the older versions.

Is there a simple way to check whether I have the right versions of gobject, pycairo and gtk installed? I have gobject 3.2.2, pycairo 1.8.10 and gtk 3.4.3 installed (all via MacPorts). It's possible that the MacPorts versions have some features disabled that are enabled on Linux. I can investigate further if that's the problem, but I don't know how to check. It seems like graph-tool is suppressing all the import errors, so I can't tell what I might be missing.

In the meantime, I'll commit the Portfile that will install 2.2.17.

[count0 (Tiago de Paula Peixoto)]

Hi, the exact versions of object, pycairo and gtk are not important, and there are not any special features which are required for graph-tool. These modules need only to be there, and to be importable. You should try simply:

    from gi.repository import Gtk, Gdk, GdkPixbuf
    import gobject
    import pycairo

And check what the errors are. If the above works, graph-tool's draw functions should work as well.