Thanks for all the work -- especially the updated build system and the 64-bit support.
I expect the latter will allow us to do things that were not practical with 32-bit limitations.

I encountered a number of small glitches:

1) setup fails using embedded IDL

./config/seadas_setup -em
./config/seadas_setup: line 18: [: -em: integer expression expected
./config/seadas_setup: line 27: idl: command not found

Patch:

*** seadas_setup.orig  2010-11-26 17:15:49.000000000 -0400
--- seadas_setup  2010-11-29 21:37:34.357314028 -0400
***************
*** 15,24 ****
  ARGV=$#
 
  if [ ${ARGV} -gt 0 ]; then
!     if [ "$1" -eq "-em" ]; then
        export RT="-em=$SEADAS/idl_rt/seadas_startup.sav"
!       export IDL_DIR= $SEADAS/idl_rt
!       export IDL_PATH= $SEADAS/idl_rt
      fi
  fi
 
--- 15,24 ----
  ARGV=$#
 
  if [ ${ARGV} -gt 0 ]; then
!     if [ "X$1" = "X-em" ]; then
        export RT="-em=$SEADAS/idl_rt/seadas_startup.sav"
!       export IDL_DIR=$SEADAS/idl_rt
!       export IDL_PATH=$SEADAS/idl_rt
      fi
  fi

2) shared library problems

The patch allows the setup to run, but then, on Ubuntu 10.10 x86_64:

$ seadas -em
IDL Version 7.0 (linux x86_64 m64). (c) 2007, ITT Visual Information Solutions

% Embedded IDL: NASA GSFC SeaDAS Development, SeaDAS.
% Embedded IDL: NASA GSFC SeaDAS Development, SeaDAS.

then gives an error panel because IDLshare.so

$ file /export/nasa/SeaDAS/6.2/build/lib/IDLshare.so
/export/nasa/SeaDAS/6.2/build/lib/IDLshare.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, not stripped
gives an error panel stating that IDLshare.so can't be loaded. 

There are also problems with the macosx IDLshare.so library.  It seems there are intel shared libraries in the source package, so it is important to
unpack the macosx_intel archive after the source archive.   The macosx shared library was build assuming libgfortran.3.dylib is in /usr/local/lib,
but I'm using macports which puts the library in /opt/local/lib/gcc45/i386.  Putting a symbolic link in /usr/local/lib gets the seadas menu, but I
expect there may be other dylib problems to sort.

3) config/sedas.env glitches

The generated config/seadas.env sets SEADAS after it is used, but fails to set SDSDATA.  Also, there are some hard-coded paths (at least on macosx --
/Users/seadas/6.2/...

4) missing $SEADAS/var/seawifs directory (for seawifs_update_elements_orbit.csh)

Again, thanks for all the hard work.

George,

Thanks for the quick response

The embedded script issue was an oops in that I'd fixed it, but forgot to commit the change before I
bundled the distro.  Thanks for catching that one.

Correct on the IDLshare.so issue.  Shouldn't be in the source package - is now removed.

As for the gfortran issue :

> Putting a symbolic link in /usr/local/lib gets the seadas menu, but I expect there may be other dylib problems to sort.

Your solution should be all that is necessary (it is in fact how my system is set up).

The SDSDATA variable is one of several that are no longer necessary.  It has been replaced by OCDATAROOT.  However,
there were a couple of places in the code where I forgot to make the change.   These have now been fixed.
There were hard-coded paths in the previous versions of the seadas.env file.  I'll work on making them relative
to $SEADAS (or $OCDATAROOT).

The run/var directory has been restored to the seadas_processing_common.tar.gz

If you find any other issues, please don't hesitate to pass them along

Thanks,
Sean

Thanks for the fast response.   Things seem to be working on the test systems (MacOSX Snow Leopard, Ubuntu 10.10 and_64, RHEL 5.5 amd_64).  I'll
try to find another victim where I can try the updated packages.

The problem with finding libgfortran also occurs with RHEL.  I don't have root access on the "production" system, but the following
~/.seadas/seadas.env_user_bash seems to work (code stolen from the IDL script).  Normally I don't like using LD_LIBRARY_PATH,
so at some point I'll need to rebuild with -rpath set.   As a workaround:

# set LD_LIBRARY_PATH to point to the location of
# libgfortran.3.so
NEW_TEXT="$HOME/opt/FSF/lib64:$HOME/opt/FSF/lib"
if [ "$LD_LIBRARY_PATH" = "" ]; then
    export LD_LIBRARY_PATH="$NEW_TEXT"
else
    LD_LIBRARY_PATH="$NEW_TEXT:$LD_LIBRARY_PATH"
fi

The IDLbathy routine fails here if I don't have SDSDATA set -- did you change that yesterday?

$ strings $SEADAS/run/bin/IDLbathy | grep DATA
SDSDATA

I'm pondering the libgfortran issue -  previous builds used ifort...

Yes and no on the SDSDATA issue - the library that IDLbathy uses was updated,
but I forgot to rebuild the binary before I put the revised tarballs on the FTP site - so if you
were to rebuild it, SDSDATA would be replace by OCDATAROOT - otherwise
SDSDATA is still looked for...bummer... 

Sean

I believe I've solved the libgfortran issue.  We're working on some additional
third party library updates, and once those are in place I'll update the packages
on the FTP site.

Thanks again for giving the code a whirl

Sean

We do have ifort here, but only for a few machines, and many people working with SeaDAS are on tight budgets and will appreciate being able to use gfortran.  For us, it makes it easier to have test/experimental SeaDAS installations (e.g., in VM's).    

The issue I was worried about is that users (unless rebuilding SeaDAS) shouldn't need to have any compilers
let alone any specific one   I'm fairly confident that I've resolved the shared object issue you discovered for me. 
If you rebuild the code, obviously, you'll need a compiler - and gfortran works (at least the more recent versions)

Sean

Well, that's the issue George discovered.  The fix hasn't been put on the FTP site yet.
Once it is, you shouldn't need gfortran at all (unless you intend to rebuild from source).

As for the transposition of modis and dem from your earlier post - fixed.

Sean

I'm not sure gfortran44 will work for compiles, although maybe the runtime is OK in the binary distro.  I build gcc4.5.1 from sources on RHEL 5.5 here.   Ubuntu 10.10 has a package for gfortran 4.5.1.  See <http://gcc.gnu.org/wiki/GFortran#GCC4.5> entry on common blocks.  The bug report linked there has a test program.  With older
gfortran you may see warnings such as:

$ gfortran43 t.f90 -o t-gfortran43
t.f90:11.12:

program test
            1
Warning: COMMON '__BLNK__' at (1) requires 4 bytes of padding at start

gfortran4.4 should work IF the third-party libraries are also rebuilt against it.
This is the version of gfortran we're using for the PPC Mac build.
You will likely run into problems if you try building the OCSSW code
with gfortran4.4 on Linux, without rebuilding lib3, which was built with 4.5.
I'll make no guarantees, though

Sean

I didn't do a rebuild. Just tried to install and run. Then figured out I needed the gfortran44 to make that happen. Don't know what other errors may crop up. l2gen seems to work fine, but was about 3 secondes slower that the 32 bit Seadas 6.1.

The slowness may be attributed to the fact that one of the libraries as distributed was built without optimization.
This was required, as adding optimization prevented the code from compiling.  Late last week we resolved
that issue and when the final release is distributed, the code should be as optimized as possible

Thanks for testing
Sean

I just installed 6.2 on linux_64 (RHEL 5.5).   IDL_bathy still wants SDSDATA (set to $SEADAS/run/data)

$ . opt/nasa/SeaDAS/6.2/config/seadas.env
Linux 64bit
$ ls -l $(which IDLbathy)
-rwxr-xr-x 1 X Y 802082 Jan  3 14:28 /home/X/opt/nasa/SeaDAS/6.2/run/bin/IDLbathy
$ strings  $(which IDLbathy) | grep DATA
?SDSDATA