[yt-users] problem installing yt on kraken

Matthew Turk matthewturk at gmail.com
Thu Jan 27 08:20:34 PST 2011


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 at 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 at 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 at 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 at yahoo.com
>> > http://stephenskory.com/
>> > 510.621.3687 (google voice)
>> > _______________________________________________
>> > 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