[yt-users] problem installing yt on kraken

Britton Smith brittonsmith at gmail.com
Thu Jan 27 09:14:33 PST 2011


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 at 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 at 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
>>
>> 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/
>> >> > <tel:+15106213687>510.621.3687 <tel:+15106213687> (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
>> >
>> >
>> _______________________________________________
>> yt-users mailing list
>> yt-users at lists.spacepope.org
>> http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.spacepope.org/pipermail/yt-users-spacepope.org/attachments/20110127/88dc12f8/attachment.html>


More information about the yt-users mailing list