Re: [yt-users] problem installing yt on kraken
Geoffrey,
Stephen is the expert for YT on Kraken, something about the scratch disk cannot see the home directories when running jobs and requires static linked libraries.
That is not entirely correct anymore, and I don't think that is what Britton's problem is. Yes, the compute nodes cannot see the home disk, but I think Britton is building things using a login node. So disk visibility should not be his problem. Also, Kraken now supports shared object loading, so the static build option that I am renowned for (?!) isn't necessary unless you want to run python/yt inline, which is what Britton is trying to do. As to Britton's problem, I don't know what is going on, sorry! Stephen Skory stephenskory@yahoo.com http://stephenskory.com/ 510.621.3687 (google voice)
Hi all,
Geoffrey -- Stephen's right Britton's experimenting with using shared
libraries as linked from Enzo, which isn't quite as applicable. The
idea being that a static compilation is a great deal of work; most
(but not all) of the time spent in symbol loading is frontloaded to
the calculation, so a shared library loading can be efficient at
medium scales. (Certainly more efficient that building statically, if
you look at wall clock time from the beginning of your time investment
to the end results.)
Additionally, I believe that the static compile option is now somewhat
easier than we previously thought, because in recent memory Python has
added the option to explicitly request the CXX compiler be used for
linking rather than LD or CC. I tested this myself last month and I
was able to get a static build without too much trouble; I was not,
however, able to get "Freeze" to work on it, which would have frozen
the .py files into .c files, built a single executable containing all
the symbols, and all around been pretty rad.
Britton -- I've run a set of tests on triton and I was not able to
replicate the problem you see. BUT, in doing so, I think I remember
seeing this with a hand-built installation a while back. I believe
the solution is to set the environment variable LDFLAGS in the
install_script.sh. There may be a more permanent way of doing this,
but I don't know what it is. I set mine (back then) in my environment
variables, but you should be able to add this line:
LDFLAGS="-L${DEST_DIR}/lib"
just below the line YT_DIR="" in the installation script. If you can
give that a shot, I think it might clear things up. As a quick note,
you should avoid linking against the whatever/config/ directory,
because it contains the .a file, whereas you want the .so file which
is just under lib.
Good luck,
Matt
On Wed, Jan 26, 2011 at 6:49 PM, Stephen Skory
Geoffrey,
Stephen is the expert for YT on Kraken, something about the scratch disk cannot see the home directories when running jobs and requires static linked libraries.
That is not entirely correct anymore, and I don't think that is what Britton's problem is. Yes, the compute nodes cannot see the home disk, but I think Britton is building things using a login node. So disk visibility should not be his problem. Also, Kraken now supports shared object loading, so the static build option that I am renowned for (?!) isn't necessary unless you want to run python/yt inline, which is what Britton is trying to do. As to Britton's problem, I don't know what is going on, sorry!
Stephen Skory stephenskory@yahoo.com http://stephenskory.com/ 510.621.3687 (google voice) _______________________________________________ yt-users mailing list yt-users@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
Hi Matt and all,
Thanks for the advice. I tried setting the LDFLAGS variable, but got the
same outcome. I tried again after adding the appropriate stuff to PATH,
PYTHONPATH, and LD_LIBRARY_PATH, with no luck. Then, I simple went into the
numpy source dir that was created by the install script and did "python
setup.py install" and everything went fine. Matt, what is different about
the install script than just doing what I did?
Britton
On Thu, Jan 27, 2011 at 8:29 AM, Matthew Turk
Hi all,
Geoffrey -- Stephen's right Britton's experimenting with using shared libraries as linked from Enzo, which isn't quite as applicable. The idea being that a static compilation is a great deal of work; most (but not all) of the time spent in symbol loading is frontloaded to the calculation, so a shared library loading can be efficient at medium scales. (Certainly more efficient that building statically, if you look at wall clock time from the beginning of your time investment to the end results.)
Additionally, I believe that the static compile option is now somewhat easier than we previously thought, because in recent memory Python has added the option to explicitly request the CXX compiler be used for linking rather than LD or CC. I tested this myself last month and I was able to get a static build without too much trouble; I was not, however, able to get "Freeze" to work on it, which would have frozen the .py files into .c files, built a single executable containing all the symbols, and all around been pretty rad.
Britton -- I've run a set of tests on triton and I was not able to replicate the problem you see. BUT, in doing so, I think I remember seeing this with a hand-built installation a while back. I believe the solution is to set the environment variable LDFLAGS in the install_script.sh. There may be a more permanent way of doing this, but I don't know what it is. I set mine (back then) in my environment variables, but you should be able to add this line:
LDFLAGS="-L${DEST_DIR}/lib"
just below the line YT_DIR="" in the installation script. If you can give that a shot, I think it might clear things up. As a quick note, you should avoid linking against the whatever/config/ directory, because it contains the .a file, whereas you want the .so file which is just under lib.
Good luck,
Matt
Geoffrey,
Stephen is the expert for YT on Kraken, something about the scratch disk cannot see the home directories when running jobs and requires static linked libraries.
That is not entirely correct anymore, and I don't think that is what Britton's problem is. Yes, the compute nodes cannot see the home disk, but I
On Wed, Jan 26, 2011 at 6:49 PM, Stephen Skory
wrote: think Britton is building things using a login node. So disk visibility should not be his problem. Also, Kraken now supports shared object loading, so the static build option that I am renowned for (?!) isn't necessary unless you want to run python/yt inline, which is what Britton is trying to do. As to Britton's problem, I don't know what is going on, sorry! Stephen Skory stephenskory@yahoo.com http://stephenskory.com/ 510.621.3687 tel:+15106213687 (google voice) _______________________________________________ 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 Britton,
I'm not sure. It should be the same outcome. ... except that I think
I meant to write in my email that you should put:
export LDFLAGS="-L${DEST_DIR}/lib"
instead of just setting the variable. I think that may have been the
problem. I'm glad that it works now, however -- and I'm sorry for my
typo.
-Matt
On Thu, Jan 27, 2011 at 11:14 AM, Britton Smith
Hi Matt and all,
Thanks for the advice. I tried setting the LDFLAGS variable, but got the same outcome. I tried again after adding the appropriate stuff to PATH, PYTHONPATH, and LD_LIBRARY_PATH, with no luck. Then, I simple went into the numpy source dir that was created by the install script and did "python setup.py install" and everything went fine. Matt, what is different about the install script than just doing what I did?
Britton
On Thu, Jan 27, 2011 at 8:29 AM, Matthew Turk
wrote: Hi all,
Geoffrey -- Stephen's right Britton's experimenting with using shared libraries as linked from Enzo, which isn't quite as applicable. The idea being that a static compilation is a great deal of work; most (but not all) of the time spent in symbol loading is frontloaded to the calculation, so a shared library loading can be efficient at medium scales. (Certainly more efficient that building statically, if you look at wall clock time from the beginning of your time investment to the end results.)
Additionally, I believe that the static compile option is now somewhat easier than we previously thought, because in recent memory Python has added the option to explicitly request the CXX compiler be used for linking rather than LD or CC. I tested this myself last month and I was able to get a static build without too much trouble; I was not, however, able to get "Freeze" to work on it, which would have frozen the .py files into .c files, built a single executable containing all the symbols, and all around been pretty rad.
Britton -- I've run a set of tests on triton and I was not able to replicate the problem you see. BUT, in doing so, I think I remember seeing this with a hand-built installation a while back. I believe the solution is to set the environment variable LDFLAGS in the install_script.sh. There may be a more permanent way of doing this, but I don't know what it is. I set mine (back then) in my environment variables, but you should be able to add this line:
LDFLAGS="-L${DEST_DIR}/lib"
just below the line YT_DIR="" in the installation script. If you can give that a shot, I think it might clear things up. As a quick note, you should avoid linking against the whatever/config/ directory, because it contains the .a file, whereas you want the .so file which is just under lib.
Good luck,
Matt
On Wed, Jan 26, 2011 at 6:49 PM, Stephen Skory
wrote: Geoffrey,
Stephen is the expert for YT on Kraken, something about the scratch disk cannot see the home directories when running jobs and requires static linked libraries.
That is not entirely correct anymore, and I don't think that is what Britton's problem is. Yes, the compute nodes cannot see the home disk, but I think Britton is building things using a login node. So disk visibility should not be his problem. Also, Kraken now supports shared object loading, so the static build option that I am renowned for (?!) isn't necessary unless you want to run python/yt inline, which is what Britton is trying to do. As to Britton's problem, I don't know what is going on, sorry!
Stephen Skory stephenskory@yahoo.com http://stephenskory.com/ 510.621.3687 (google voice) _______________________________________________ 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,
Just for the record, I tried this and it does work. Thanks!
Britton
On Thu, Jan 27, 2011 at 11:20 AM, Matthew Turk
Hi Britton,
I'm not sure. It should be the same outcome. ... except that I think I meant to write in my email that you should put:
export LDFLAGS="-L${DEST_DIR}/lib"
instead of just setting the variable. I think that may have been the problem. I'm glad that it works now, however -- and I'm sorry for my typo.
-Matt
Hi Matt and all,
Thanks for the advice. I tried setting the LDFLAGS variable, but got the same outcome. I tried again after adding the appropriate stuff to PATH, PYTHONPATH, and LD_LIBRARY_PATH, with no luck. Then, I simple went into
numpy source dir that was created by the install script and did "python setup.py install" and everything went fine. Matt, what is different about the install script than just doing what I did?
Britton
On Thu, Jan 27, 2011 at 8:29 AM, Matthew Turk
wrote: Hi all,
Geoffrey -- Stephen's right Britton's experimenting with using shared libraries as linked from Enzo, which isn't quite as applicable. The idea being that a static compilation is a great deal of work; most (but not all) of the time spent in symbol loading is frontloaded to the calculation, so a shared library loading can be efficient at medium scales. (Certainly more efficient that building statically, if you look at wall clock time from the beginning of your time investment to the end results.)
Additionally, I believe that the static compile option is now somewhat easier than we previously thought, because in recent memory Python has added the option to explicitly request the CXX compiler be used for linking rather than LD or CC. I tested this myself last month and I was able to get a static build without too much trouble; I was not, however, able to get "Freeze" to work on it, which would have frozen the .py files into .c files, built a single executable containing all the symbols, and all around been pretty rad.
Britton -- I've run a set of tests on triton and I was not able to replicate the problem you see. BUT, in doing so, I think I remember seeing this with a hand-built installation a while back. I believe the solution is to set the environment variable LDFLAGS in the install_script.sh. There may be a more permanent way of doing this, but I don't know what it is. I set mine (back then) in my environment variables, but you should be able to add this line:
LDFLAGS="-L${DEST_DIR}/lib"
just below the line YT_DIR="" in the installation script. If you can give that a shot, I think it might clear things up. As a quick note, you should avoid linking against the whatever/config/ directory, because it contains the .a file, whereas you want the .so file which is just under lib.
Good luck,
Matt
On Wed, Jan 26, 2011 at 6:49 PM, Stephen Skory
wrote: Geoffrey,
Stephen is the expert for YT on Kraken, something about the scratch disk cannot see the home directories when running jobs and requires static linked libraries.
That is not entirely correct anymore, and I don't think that is what Britton's problem is. Yes, the compute nodes cannot see the home disk,
but I
think Britton is building things using a login node. So disk visibility should not be his problem. Also, Kraken now supports shared object loading, so the static build option that I am renowned for (?!) isn't necessary unless you want to run python/yt inline, which is what Britton is
On Thu, Jan 27, 2011 at 11:14 AM, Britton Smith
wrote: the trying to do. As to Britton's problem, I don't know what is going on, sorry!
Stephen Skory stephenskory@yahoo.com http://stephenskory.com/ 510.621.3687 tel:+15106213687 (google voice) _______________________________________________ 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
Sorry to be sounding like an idiot. I tried the above from scratch and it
actually failed the way it did the first time. It only worked because I
reran the install_script after building numpy by hand. I also get the same
error on the Cython install, but building it by hand also works there, too.
Britton
On Thu, Jan 27, 2011 at 11:24 AM, Britton Smith
Hi Matt,
Just for the record, I tried this and it does work. Thanks!
Britton
On Thu, Jan 27, 2011 at 11:20 AM, Matthew Turk
wrote: Hi Britton,
I'm not sure. It should be the same outcome. ... except that I think I meant to write in my email that you should put:
export LDFLAGS="-L${DEST_DIR}/lib"
instead of just setting the variable. I think that may have been the problem. I'm glad that it works now, however -- and I'm sorry for my typo.
-Matt
Hi Matt and all,
Thanks for the advice. I tried setting the LDFLAGS variable, but got
same outcome. I tried again after adding the appropriate stuff to PATH, PYTHONPATH, and LD_LIBRARY_PATH, with no luck. Then, I simple went into
numpy source dir that was created by the install script and did "python setup.py install" and everything went fine. Matt, what is different about the install script than just doing what I did?
Britton
On Thu, Jan 27, 2011 at 8:29 AM, Matthew Turk
wrote: Hi all,
Geoffrey -- Stephen's right Britton's experimenting with using shared libraries as linked from Enzo, which isn't quite as applicable. The idea being that a static compilation is a great deal of work; most (but not all) of the time spent in symbol loading is frontloaded to the calculation, so a shared library loading can be efficient at medium scales. (Certainly more efficient that building statically, if you look at wall clock time from the beginning of your time investment to the end results.)
Additionally, I believe that the static compile option is now somewhat easier than we previously thought, because in recent memory Python has added the option to explicitly request the CXX compiler be used for linking rather than LD or CC. I tested this myself last month and I was able to get a static build without too much trouble; I was not, however, able to get "Freeze" to work on it, which would have frozen the .py files into .c files, built a single executable containing all the symbols, and all around been pretty rad.
Britton -- I've run a set of tests on triton and I was not able to replicate the problem you see. BUT, in doing so, I think I remember seeing this with a hand-built installation a while back. I believe the solution is to set the environment variable LDFLAGS in the install_script.sh. There may be a more permanent way of doing this, but I don't know what it is. I set mine (back then) in my environment variables, but you should be able to add this line:
LDFLAGS="-L${DEST_DIR}/lib"
just below the line YT_DIR="" in the installation script. If you can give that a shot, I think it might clear things up. As a quick note, you should avoid linking against the whatever/config/ directory, because it contains the .a file, whereas you want the .so file which is just under lib.
Good luck,
Matt
On Wed, Jan 26, 2011 at 6:49 PM, Stephen Skory
wrote:
Geoffrey,
Stephen is the expert for YT on Kraken, something about the scratch disk cannot see the home directories when running jobs and requires static linked libraries.
That is not entirely correct anymore, and I don't think that is what Britton's problem is. Yes, the compute nodes cannot see the home disk, but I think Britton is building things using a login node. So disk visibility should not be his problem. Also, Kraken now supports shared object loading, so the static build option that I am renowned for (?!) isn't necessary unless you want to run python/yt inline, which is what Britton is
On Thu, Jan 27, 2011 at 11:14 AM, Britton Smith
wrote: the the trying to do. As to Britton's problem, I don't know what is going on, sorry!
Stephen Skory stephenskory@yahoo.com http://stephenskory.com/ tel:+15106213687510.621.3687 tel:+15106213687 (google voice) _______________________________________________ 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 (3)
-
Britton Smith
-
Matthew Turk
-
Stephen Skory