[SciPy-User] worst-case scenario installation
Johann Cohen-Tanugi
cohen at lpta.in2p3.fr
Wed Aug 19 16:45:14 EDT 2009
we would probably need your site.cfg file as well.... did you modify it?
Johann
Johann Cohen-Tanugi wrote:
> We need some more info like your LD_LIBRARY_PATH and the output of ldd
> on the various libraries that have problems. One thing you can try to do
> is make sure that you dont link to unwanted versions of BLAS etc... by
> creating soft links in $HOME/lib and resetting your LD_LIBRARY_PATH
> The fact that g77 and gfortran are both in /usr/bin is completely
> inocuous, as Robert mentioned : it is probably the case for many if not
> all of us.
>
> and yes..... directly building sage is a very nice way to avoid this
> definitely slightly tricky part of the built.
>
> Johann
>
> DEMOLISHOR! the Demolishor wrote:
>
>> Folks,
>> There is mounting evidence to suggest that I cannot install SciPy/
>> Numpy under these restrictions:
>>
>> - I do not have root access to my machine
>> - I use a later version of Python than my distribution provides (2.6
>> instead of 2.4--I am using RHEL5), built locally and installed in
>> $HOME/bin -- this prevents me from asking my sysadmin to install
>> numpy and scipy from the YUM repositories.
>> - both g77 and gfortran are installed in /usr/bin and thus I cannot
>> modify my path to exclude g77 without fear of crippling the rest of
>> the build system in mysterious ways.
>>
>> So here's what happens:
>> - Using hand-built versions of ATLAS and LAPACK (following the
>> instructions on the ATLAS website) result in undefined reference
>> errors in liblapack.so to function calls that live in libblas.so
>> - Using RPM versions of ATLAS and LAPACK from a RPM search site (I
>> just extracted and copied the libraries and headers into the relevant
>> directories) breaks down in the same way, and no RPM exists with these
>> libraries
>> built with g77.
>> - Building ATLAS by hand using the instructions on the SciPy
>> website
>> (http://www.scipy.org/Installing_SciPy/Linux#head-89e1f6afaa3314d98a22c79b063cceee2cc6313c)
>> also breaks down because I cannot avoid having g77 in my path. Also I
>> can no longer build LAPACK with g77
>> (http://www.netlib.org/lapack/lapack-3.2.html#_7_install_procedure).
>>
>> The most aggravating part of this entire process is that I am going
>> through all these gyrations to avoid the Numpy setup script's
>> obsession with g77. I do not understand why the `--fcompiler' option
>> doesn't work , or even putting gfortran ahead of g77 in my PATH. I
>> realize I am not a typical user, but these things seem really simple
>> to fix for someone that knows where to look.
>>
>> And as I was writing this, I figured this out:
>> I ended up linking *everything* in /usr/bin to ~/bin, removing
>> /usr/bin from my PATH, and then removing the links to g77 and f77 from
>> ~/bin, and rebuilding. Now Numpy fails 1 test, and SciPy fails 4, and
>> I guess if I am lucky I'll never need the stuff that doesn't pass the
>> tests. So it was *not* impossible to install an at least partial
>> version of Scipy/Numpy on my system.
>>
>> Bottom line: weird people like me shouldn't suffer because of
>> unimplemented command-line options. That said, weird people are like
>> me are grateful that stuff like Scipy and Numpy exist because they
>> keep me from having to use ROOT.
>>
>> Thanks,
>> Craig
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> SciPy-User mailing list
>> SciPy-User at scipy.org
>> http://mail.scipy.org/mailman/listinfo/scipy-user
>>
>>
> _______________________________________________
> SciPy-User mailing list
> SciPy-User at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-user
>
More information about the SciPy-User
mailing list