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
Hi Stella,
On Mon, May 23, 2011 at 11:02 AM, Stella Offner
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@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
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
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@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
_______________________________________________ yt-users mailing list yt-users@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
Hi Stella,
Could you send me yt_install.log, off-list?
Thanks,
Matt
On Mon, May 23, 2011 at 12:04 PM, Stella Offner
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
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@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
_______________________________________________ yt-users mailing list yt-users@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
_______________________________________________ yt-users mailing list yt-users@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
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
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
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@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
_______________________________________________ yt-users mailing list yt-users@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
_______________________________________________ yt-users mailing list yt-users@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
_______________________________________________ yt-users mailing list yt-users@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
participants (2)
-
Matthew Turk
-
Stella Offner