[yt-users] Mecurial compilation error

[Matthew Turk]

Hi Stella,

On Mon, May 23, 2011 at 11:02 AM, Stella Offner <soffner at cfa.harvard.edu> wrote:
> Hi,
>
> I'm attempting to install a new version of yt on the Harvard Odyssey machine
> (dual Xeon quad core). The install fails when building mecurial. Does anyone
> recognize this error?
> ...
> running build_ext
> building 'mercurial.base85' extension
> creating build/temp.linux-x86_64-2.7
> creating build/temp.linux-x86_64-2.7/mercurial
> gcc -pthread -fno-strict-aliasing -g -O2 -DNDEBUG -g -fwrapv -O3 -Wall
> -Wstrict-prototypes -fPIC -I/n/sw/python-2.7/include/python2.7 -c
> mercurial/base85.c -o build/temp.linux-x86_64-2.7/mercurial/base85.o
> gcc -pthread -shared -L/n/home05/soffner/yt-x86_64/lib/
> -L/n/home05/soffner/yt-x86_64/lib64/ -L/n/home05/soffner/yt-x86_64/lib/
> -L/n/home05/soffner/yt-x86_64/lib64/ -L/n/home05/soffner/yt-x86_64/lib/
> -L/n/home05/soffner/yt-x86_64/lib64/ -L/n/home05/soffner/yt-x86_64/lib/
> -L/n/home05/soffner/yt-x86_64/lib64/
> build/temp.linux-x86_64-2.7/mercurial/base85.o -L. -lpython2.7 -o
> build/lib.linux-x86_64-2.7/mercurial/base85.so
> /usr/bin/ld: /n/home05/soffner/yt-x86_64/lib//libpython2.7.a(exceptions.o):
> relocation R_X86_64_32 against `_Py_NoneStruct' can not be used when making
> a shared object; recompile with -fPIC
> /n/home05/soffner/yt-x86_64/lib//libpython2.7.a: could not read symbols: Bad
> value
> collect2: ld returned 1 exit status
> error: command 'gcc' failed with exit status 1
>
> Python 2.7 seems to work ok, so I don't know what the deal is with the
> libpython2.7a error.
> Thanks,
> Stella

Unfortunately I do recognize this error.  The PIC error is related to
"position independent code".  This shows up when you try to link
against a static library from within a shared library, which is what's
going on here.  (Having non-PIC code gains you an extra register,
which is arguably a Big Deal.)  There are two solutions to it -- one
is to ensure that all the static libraries, like python, are compiled
and linked with -fPIC.  The other is to avoid building static
libraries, which is something we should probably be doing anyway.

To get around this, I'd suggest wiping the current directory structure
so that you can make sure everything is consistent, and on line 430 of
the install_script changing this:

( ./configure --prefix=${DEST_DIR}/ 2>&1 ) 1>> ${LOG_FILE} || do_exit

to this:

( ./configure --enable-shared --prefix=${DEST_DIR}/ 2>&1 ) 1>>
${LOG_FILE} || do_exit

If this works for you, I'll make it the default in the install script.
 I would contest this is how it should be anyway, since any benefits
to static linking -- like having an all-in-one Python, for CNL or for
frozen embedded stuff -- are generally outside the realm of the
install script anyway.

-Matt

>
> _______________________________________________
> yt-users mailing list
> yt-users at lists.spacepope.org
> http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
>