[yt-users] Mecurial compilation error

Matthew Turk matthewturk at gmail.com
Mon May 23 09:07:41 PDT 2011


Hi Stella,

Could you send me yt_install.log, off-list?

Thanks,

Matt

On Mon, May 23, 2011 at 12:04 PM, Stella Offner <soffner at cfa.harvard.edu> wrote:
> Hi Matt,
>
> Thanks, that worked. However, even though the install seems successful now
> the script complains it can't find the mecurial libraries:
> /n/home05/soffner/yt-x86_64/bin/python2.7: can't open file
> '/n/home05/soffner/yt-x86_64/src/yt-hg//distribute_setup.py': [Errno 2] No
> such file or directory
> abort: couldn't find mercurial libraries in
> [/n/home05/soffner/yt-x86_64/python/2.7/site-packages
> /n/home05/soffner/yt-x86_64/bin
> /n/sw/python-2.7/lib/python2.7/site-packages/h5py-1.3.1_beta-py2.7-linux-x86_64.egg
> /n/sw/python-2.7/lib/python2.7/site-packages/lxml-2.3beta1-py2.7-linux-x86_64.egg
> /n/sw/python-2.7/lib/python2.7/site-packages/httplib2-0.6.0-py2.7.egg
> /n/home05/soffner/yt-x86_64/lib/python2.7/site-packages
> /n/sw/python-2.7/lib/python27.zip /n/sw/python-2.7/lib/python2.7
> /n/sw/python-2.7/lib/python2.7/plat-linux2
> /n/sw/python-2.7/lib/python2.7/lib-tk /n/sw/python-2.7/lib/python2.7/lib-old
> /n/sw/python-2.7/lib/python2.7/lib-dynload
> /n/sw/python-2.7/lib/python2.7/site-packages]
>
> I don't see them anywhere else in my home directory either...
> Thanks,
> Stella
>
> Matthew Turk wrote:
>>
>> 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
>>>
>>>
>>
>> _______________________________________________
>> yt-users mailing list
>> yt-users at lists.spacepope.org
>> http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
>>
>
> _______________________________________________
> yt-users mailing list
> yt-users at lists.spacepope.org
> http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
>



More information about the yt-users mailing list