Re: [igraph] Trouble building igraph

[Tamas Nepusz]

> 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