[yt-users] Mecurial compilation error

Stella Offner soffner at cfa.harvard.edu
Mon May 23 09:13:05 PDT 2011


Hi Matt,

I have attached the log. There is a previous error that it can't find 
*/bin/hg. I found that hg had been installed in $HOME/usr/bin and moved 
it to the expected location. So perhaps something like that is happening 
to the mecurial libraries (although I don't see them in usr/*. Thanks 
for your help. Sorry for the trouble!

Stella


Matthew Turk wrote:
> 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
>>
>>     
> _______________________________________________
> yt-users mailing list
> yt-users at lists.spacepope.org
> http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
>   

-------------- next part --------------
A non-text attachment was scrubbed...
Name: yt_install.log
Type: text/x-log
Size: 2629285 bytes
Desc: not available
URL: <http://lists.spacepope.org/pipermail/yt-users-spacepope.org/attachments/20110523/36a72a33/attachment-0001.bin>


More information about the yt-users mailing list