"/home/vimal/seadas/ocssw/run/scripts/ocssw_runner: line 21: pyverchk.py: command not found
Error - Python version is not new enough to install luts".
It could be useful to know the Ubuntu version. What do you get when you run the following command in a terminal:
ls -l /home/vimal/seadas/ocssw/run/scripts/pyverchk.py? Is your python the verson supplied by the distribution or
did you install it separately (e.g., using the Anaconda distribution)?
I've installed SeaDAS 7.4 on many linux systems and not seen this error, so it is possible that your system has some other problem such as a full disk or permission conflicts.
(Note from the admin - post moved as suggested :grin:)
Through distribution i installed Python not by separately. while running the command "ls -l /home/vimal/seadas/ocssw/run/scripts/pyverchk.py"
"-rwxrwxr-x 1 vimal vimal 2300 Mar 13 09:29 /home/vimal/seadas/ocssw/run/scripts/pyverchk.py".
And how to find the full disk or permission conflicts? what i have to do for resolving these conflicts?
And my friends/colleagues who already installed seadas in Linux system getting the same error while "update OC processor".
OCSSW_bash.envfile. This version sets the PATH variable to directories that don't match the locations in version 7.4. The
install_ocssw.pyscript replaces the existing file with OCSSW_bash.env To see if this is your problem, run
ls -l ~/seadas/ocssw/OCSSW_bash.env. For version 7.4 this should be 2894 bytes, but the current installer gives a version with 3001 bytes.
- Subject Matter Expert
- Posts: 256
- Joined: Thu Mar 05, 2009 10:25 am America/New_York
- Been thanked: 2 times
Try updating OCSSW. It should work now.
while run "ls -l ~/seadas/ocssw/OCSSW_bash.env",
I got "-rw-rw-r-- 1 vimal vimal 3001 Nov 14 02:06 /home/vimal/seadas/ocssw/OCSSW_bash.env".
After update its working fine now "-rw-rw-r-- 1 vimal vimal 2894 Mar 14 22:36 /home/vimal/seadas/ocssw/OCSSW_bash.env".
Thank you very much!
checking for string.h... (cached) yes
checking stdio.h usability... yes
checking stdio.h presence... yes
checking for stdio.h... yes
checking for stdlib.h... (cached) yes
checking locale.h usability... yes
checking locale.h presence... yes
checking for locale.h... yes
checking for debug enabled... no
checking for exp in -lm... yes
checking zlib.h usability... yes
checking zlib.h presence... yes
checking for zlib.h... yes
checking for library containing inflateInit_... -lz
using zlib from /usr/include
checking for library containing jinit_compress_master... -ljpeg
using jpeg from /home/vimal/seadas/ocssw/build/lib3/include
checking for TIFFOpen in -ltiff... no
configure: error: failed to link with -ltiff to find TIFFOpen
***** configure failed *****
***** BuildIt (geotiff) failed *****
But i already installed all the necessary libraries like geotiff and tiff libraries.
Building the OCSSW software is a big job, so unless your IT policies don't let you use binaries from NASA or you need to modify the programs, it saves a lot of time use the NASA supplied versions. On linux it is not enough to install libraries, you also have to install the developer packages for each library needed in the build. This can be tedious, but there are some tools (see Debian Building Tutorial) to help. This tutorial is for people building distro packages. Although the OCSSW programs aren't in Debian/Ubuntu packages, many of the 3rd party libraries have distro packages. It can be tedious if you run
BuildItover and over for every missing library, so it is faster to get devleoper packages before running
BuildIt. Also note that once a library has been build you can edit
BuildItto remove it from the list so you don't build the same library over and over. If you obtain the developer packages distro versions of the 3rd-party libraries (OCSSW provides these because distros often provide outdated versions or build them with different options) you will get most of developer packages you need. There are a few programs that are often used along with the OCSSW software, such as gdal and nco, so I generally get the developer packages needed to build gdal and nco before attempting to build the 3rd party libraries. This approach greatly reduces the number of failures with
BuildIt. Developer packages are generally small, so it doesn't hurt to have a few that won't actually be used.
I removed all the libraries which i installed manually and after that using developer package it get installed while BuildIt.