Re: [igraph] Trouble building igraph

[Jeff Alstott]

This wasn't mission critical to me at the time, and the solution looked scary, so I put it aside. A month and a half later, I actually tried the simple steps that Tamas gave and it worked. Thanks!

On Sat, Sep 27, 2014 at 3:20 AM, Tamas Nepusz <address@hidden> wrote:

> Installing python-igraph with pip install python-igraph yields a lot of
> effort and then the following error at the end:
>
> /usr/bin/ld: /usr/lib64/libm.a(s_atan.o): relocation R_X86_64_32S against
> `.rodata' can not be used when making a shared object; recompile with -fPIC
This is probably the same as the following issue (although with a different linked library):

https://github.com/igraph/igraph/issues/640

The easiest workaround would probably be to:

1. Download python-igraph-0.7.tar.gz from https://pypi.python.org/pypi/python-igraph/0.7
2. Extract it somewhere
3. Replace setup.py in the tarball with our patched one from https://raw.githubusercontent.com/igraph/igraph/develop/interfaces/python/setup.py
4. Run “python setup.py install"

The full story is (roughly) as follows (you can skip this if you are in a hurry):

1. When you run “pip install python-igraph”, the installer figures out that you have not compiled and installed the C core of igraph so it tries to download and compile the C core. To prevent complications with dynamic linkage (a dynamically compiled igraph library would have to be installed somewhere in /usr/lib or /usr/lib64 so the system could see it, and it is not nice to mess around with these locations unless done via a package manager), the C core of igraph is compiled statically and linked to the Python interface.

2. The C core of the igraph library also depends on some system libraries such as libxml2 (for parsing GraphML files) or libm (for doing all sorts of math stuff). Again, to prevent complications with dynamic linkage (the Python interface could break if it links dynamically to these libraries and the libraries are updated), the setup script will strive to link to the static copies of these libraries, i.e. to libxml2.a instead of libxml2.so.* and to libm.a instead of libm.so.*. Unfortunately, this linkage works only if the static libraries (i.e. the ones with the .a extension) are compiled with specific compiler switches, one of which is -fPIC.

3. In your case, libm.a was compiled without -fPIC (probably by the maintainers of whatever Linux flavour you are using), so the linkage does not work and you get this cryptic error message.

Actually, this is not the first time that libm.a causes problems; it also happened before with someone else on Sabayon Linux, so the development branch of our codebase already contains a new version of setup.py that links to libm dynamically - that’s what you had to download in the workaround above.

Let me know whether it worked for you or not.

All the best,
Tamas