[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [igraph] Trouble building igraph
From: |
Tamas Nepusz |
Subject: |
Re: [igraph] Trouble building igraph |
Date: |
Fri, 26 Sep 2014 21:20:02 +0200 |
> 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