Author Topic: isispgmdef ISIS initialization for Bourne Shell... (SOLVED)  (Read 7040 times)

vsfoote

  • Osiris (Active Member)
  • **
  • Posts: 6
isispgmdef ISIS initialization for Bourne Shell... (SOLVED)
« on: October 11, 2005, 04:09:14 PM »
Setting up a Fedora Core 4 system. Have RSINC Envi-4.2 & IDL-6.2 installed. rsync setup ISSI 2.3  runs to completion but now having some problem with environment variable setup for the bash shell in .bash_profile.


I Have been having the following problems:
1.) I can not get a consistant declaration of LD_LIBRARY_PATH, commands either side of the "Add ISISLIB to LD_LIBRARY_PATH" section of the isispgmdef script seem to take without problem. I can manually set the LD_LIBRARY_PATH to $ISISLIB and export it and qview works. But can't seem to configure the .bash_profile and scripts to retain the variable.

2.) should the IDL_PATH variable end up set as

        <IDL_DEFAULT>:+$ISISIDL

$ISISIDL is correctly declared, is there some impact if I comment out  the <IDL_DEFAULT> assignment, or could it be  set it to the IDL install path.

3.)  Finally, I think there may be a logic flaw in the "Adjust the path variable to include ISIS executables" section. The sh version of the script tests NOT $USERTAEBIN while the csh version has the correct test EXISTS  $USERTAEBIN. This results in an incorrect  PATH delcaration when the NULL $USERTAEBIN is appended to the PATH. A pair of :: mid path. It disapears when I fix the test.

Appreciate the help.

Stuart Foote
Univ of Texas at San Antonio
V Stuart Foote
Systems Analyst
Dept of Earth and Environmental Science, UTSA

vsfoote

  • Osiris (Active Member)
  • **
  • Posts: 6
isispgmdef ISIS initialization for Bourne Shell -- bash
« Reply #1 on: October 12, 2005, 02:45:25 PM »
OK I know this is bad form to  reply to my own post

But, I think I've corrected the LD_LIBRARY_PATH problem by not using it, Instead creating a /etc/ld.so.cache entry for the $ISISLIB.  However, I'm not sure if I'll need to apply same adjustment for TAE, PERL, SPICE, or PICO apps. Doesn't seem like I'd need to since the LD_LIBRARY_PATH was only pointed to $ISISLIB.

I'm on a Fedora Core 4 (2.6.13-1.1526_FC4) Intel i686 box using bash shell.

Testing the LD_LIBRARY_PATH issue proceeded like this

login with the default isis_profile entries added to .bash_profile

echo $LD_LIBRARY_PATH returns null
printenv | grep LD_LIBRARY_PATH fails
so variable is not set even though it is plainly called in isispgmdef script in $ISISR/sys/sh directory

Results of
    ldd $ISISEX/qview
          linux-gate.so.1 =>  (ox00215000)          
          libisismpt.so => not found
          libisislev.so  => not found
          libissker.so => not found
          libisisspi.so => not found
          <etc. snip>
         libXm.so3 => /usr/X11R6/lib/libXm.so.3 (0x00644000)
         libXt.so.6 => /usr/X11/R6/lib/libXt.so.6 (0x023e0000)
         <etc. snip>
         /bin/ld-linux.so.2 (0x00278000)

manually set the shared library path
         export LD_LIBRARY_PATH=$ISISLIB
reran qview
   ldd $ISISEXE/qview
        linux-gate.so.1 =>  (0x00572000)
        libisismpt.so => /usr/local/ISIS/isisr/lib/libisismpt.so (0x004b0000)
        libisislev.so => /usr/local/ISIS/isisr/lib/libisislev.so (0x00f26000)
        libisisker.so => /usr/local/ISIS/isisr/lib/libisisker.so (0x00ce9000)
        libisisspi.so => /usr/local/ISIS/isisr/lib/libisisspi.so (0x0057b000)
        libisismath.so => /usr/local/ISIS/isisr/lib/libisismath.so (0x0041b000)
         <etc. snip>

And everything looks good. BUT THE EXPORT does not persist and from another terminal LD_LIBRARY_PATH is again not set.  Perhaps it is something with selinux, or just a Fedora quirk.

Anyhow I needed a better fix. The Linux ld.so (8) and ldconfig (8) and this TLDP link http://www.tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html provided sufficient detail to realize that I could include the ISIS shared libraries in /etc/ld.so.cache

   su root  
   cd  /etc/ld.so.conf.d
   echo $ISISLIB > usgs-ISIS-i386.conf  #any name is fine but it must be a .conf extension
   /sbin/ldconfig #lto rebuild cache, log out and back in to clear any processes

That looks to fix things. To be neat I've commented out the ISISLIB to LD_LIBRARY_PATH entry in the isispgmdef script.

For the developers, do you see any gothca's in this approach?

Thanks,

Stuart Foote
Univ of Texas at San Antonio








 :roll:
V Stuart Foote
Systems Analyst
Dept of Earth and Environmental Science, UTSA

kbecker

  • Isis Support Team
  • Isis (Extreme Power Member)
  • *****
  • Posts: 508
    • http://isis.astrogeology.usgs.gov
    • Email
Re: isispgmdef ISIS initialization for Bourne Shell -- bash
« Reply #2 on: October 13, 2005, 03:18:08 PM »
Hi Stuart...


I will address your posts in the order posted.

Quote

1.) I can not get a consistant declaration of LD_LIBRARY_PATH, commands either side of the "Add ISISLIB to LD_LIBRARY_PATH" section of the isispgmdef script seem to take without problem. I can manually set the LD_LIBRARY_PATH to $ISISLIB and export it and qview works. But can't seem to configure the .bash_profile and scripts to retain the variable.


I have found the behavior of the the bash shell when starting interactive and non-interactive shells a bit odd (I am not a Bash shell user, your YMMV).  Interactive shells execute .bash_profile, non-interactive do not.  Both, however, execute .bashrc.  Hence, that is where I suggest you put the ISIS startup commands.

Quote

2.) should the IDL_PATH variable end up set as

<IDL_DEFAULT>:+$ISISIDL

$ISISIDL is correctly declared, is there some impact if I comment out the <IDL_DEFAULT> assignment, or could it be set it to the IDL install path.


This is exactly how it is set in isispgmdef.  Note that you used to have to execute the IDL setup routines first (ex:, . /usr/local/rsi/idl/bin/idl_setup.bash), but I do not believe that is the case any longer.  <IDL_DEFAULT> is critical because that is internallly recognized within IDL and is used to include the IDL intrinsic directories/paths upon execution.  If you just set IDL_PATH excluding it, some things cease to function properly (DLMs, for example).  As far as I am concerned, that is the proper, (IDL) documented way to initialize IDL_PATH incorporating your own S/W.

Quote

3.) Finally, I think there may be a logic flaw in the "Adjust the path variable to include ISIS executables" section. The sh version of the script tests NOT $USERTAEBIN while the csh version has the correct test EXISTS $USERTAEBIN. This results in an incorrect PATH delcaration when the NULL $USERTAEBIN is appended to the PATH. A pair of :: mid path. It disapears when I fix the test.


You are correct.  I have fixed this issue and attached a new Bash-compatable isispgmdef file.  It lives in $ISISR/sys/sh.

Now...on to your second post...

Quote

But, I think I've corrected the LD_LIBRARY_PATH problem by not using it, Instead creating a /etc/ld.so.cache entry for the $ISISLIB. However, I'm not sure if I'll need to apply same adjustment for TAE, PERL, SPICE, or PICO apps. Doesn't seem like I'd need to since the LD_LIBRARY_PATH was only pointed to $ISISLIB.


I highly discourage the use of the Linux runtime cache for ISIS installations.  I generally feel that resource is for system installations only, i.e., root.  ISIS is not, and should not, be installed as root for mainly for security reasons.  LD_LIBRARY_PATH usage is appropriate and adequate for ISIS installation and use.  It is designed to be installed by individual users if need be.  Using the runtime loader cache causes ISIS libraries to have system, global scope to users/developers.  This is entirely unnecessary and, some would argue, undesireable.  It could also lead to problems with ISIS upgrades.

That said, I believe part of your problem is where you put the ISIS startup commands as I mentioned earlier.  I have just completed testing on my system and it works just fine with me reproducing only the $USERTAEBIN error.

I would suggest that you create an isis_profile file that contains the pertinent ISIS startup commands, place that in your home directory and use the following logic in your .bashrc:

Code: [Select]

if [ -f $HOME/isis_profile ]; then
  . $HOME/isis_profile
fi


Here is the contents of my isis_profile (note that yours may be totally different and is obviously dependant on your ISIS installation):

Code: [Select]

#  Contents of isis_profile
export ISIS2=/usgs/pkgs/isis2.3.0
export ISIS2BIN=/usgs/pkgs/isis2.3.0
export ISIS=$ISIS2/isis
export TAE=$ISIS2/tae
export ISISD=/usgs/cpkgs/isis2/lsb/isisd
export ISISR=$ISIS2BIN/isisr
export DEVISISR=$ISIS2BIN/isisrdev
export SPICE=$ISIS2BIN/naif
export PGPLOT=$ISIS2BIN/pgplot
export ISIS3RDPARTY=$ISIS2BIN/3rdparty

if [ -f $ISISR/sys/sh/isispgmdef ]; then
  . $ISISR/sys/sh/isispgmdef
fi

if [ -f $TAE/bin/sh/taesetup ]; then
  . $TAE/bin/sh/taesetup
  . $TAE/bin/sh/taesetupclassic
  alias tae=taetm
  export PATH=${PATH}:${TAEBIN}
fi


Quote

And everything looks good. BUT THE EXPORT does not persist and from another terminal LD_LIBRARY_PATH is again not set. Perhaps it is something with selinux, or just a Fedora quirk.


That could very well be an issue.  We do not have Fedora installed locally so we do not routinely test this Linux installation.  We cannot say how ISIS, including the initialization and system interaction, will behave on Fedora.

If you are trying it in another terminal and it is invoked as xterm& or something of that nature, the ISIS commands are not being executed if they are in .bash_profile...it is not a login shell which executes .bash_profile...non-interactive shells, xterms spawned as a subprocess or child, minimally execute .bashrc.

Quote

 su root
cd /etc/ld.so.conf.d
echo $ISISLIB > usgs-ISIS-i386.conf #any name is fine but it must be a .conf extension
/sbin/ldconfig #lto rebuild cache, log out and back in to clear any processes

That looks to fix things. To be neat I've commented out the ISISLIB to LD_LIBRARY_PATH entry in the isispgmdef script.


Again, I do not recommend this approach.  See the above discussion.

Quote

For the developers, do you see any gothca's in this approach?


Yes.  If you are not getting LD_LIBRARY_PATH exported properly, chances are that you are not getting any other ISIS environment variables exported as well.  Many of these and others (e.g., TAE, SPICE, PGPLOT) are critical to ISIS development, if that is what your intent is.

Try these suggestions and let us know how you fair.
Kris Becker
Computer Scientist
Astrogeology Team
U.S. Geological Survey