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 <stephenskory@yahoo.com> 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
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 <matthewturk@gmail.com> 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
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 <stephenskory@yahoo.com> 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 <brittonsmith@gmail.com> wrote:
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 <matthewturk@gmail.com> 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 <stephenskory@yahoo.com> 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 <matthewturk@gmail.com>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 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 <matthewturk@gmail.com> 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 <stephenskory@yahoo.com> 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 <brittonsmith@gmail.com> 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 <brittonsmith@gmail.com>wrote:
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 <matthewturk@gmail.com>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 <matthewturk@gmail.com> 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 <stephenskory@yahoo.com
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 <brittonsmith@gmail.com> 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:+15106213687>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
participants (3)
-
Britton Smith -
Matthew Turk -
Stephen Skory