[GRASS5] LD_LIBRARY_PATH and display support on solaris 8

I also had glitches starting the pre-02 version on Solaris 8. Init.sh choked.

I had to change Init.sh to

# Set LD_LIBRARY_PATH. For GRASS 5.0 we don't depend on this much, though
# r.in.gdal may use it to find some things. Over time we intend to put
# more GRASS related shared libraries in $GISBASE/lib.
if [ ! "$LD_LIBRARY_PATH" ] ; then
   LD_LIBRARY_PATH=$GISBASE/lib:/usr/lib:/usr/local/lib:/usr/openwin/lib
   export LD_LIBRARY_PATH
else
  LD_LIBRARY_PATH=$GISBASE/lib:/usr/lib:/usr/local/lib:/usr/openwin/lib: $LD_LIBR
ARY_PATH
fi

so that $ETC/set_data could find the zlib shared library.

The key is that if --with-zlib-libs=DIR is specified to "configure", then that directory has to end up in the LD_LIBRARY_PATH. I don't know where in the build tree that change should be made, however.

I also ran into the problem of the display/d.mon stuff getting built with inconsistent references to sockets and fifos. Specified --with-fifo and everything worked fine. As someone else had noted, the compile goes fine without saying --with-fifo; it's only at runtime that the problem arises.

Hal
----
Hal Mueller hal@seanet.com
Mobile Geographics LLC http://www.mobilegeographics.com/
Seattle, Washington (206) 297-9575
Get CelestNav 2.2.2! http://www.mobilegeographics.com/celestnav/

On Thu, 18 Oct 2001 21:06:17 -0700, Hal Mueller <hal@seanet.com> wrote:

The key is that if --with-zlib-libs=DIR is specified to
"configure", then that directory has to end up in the
LD_LIBRARY_PATH. I don't know where in the build tree that change
should be made, however.

I don't know how the runtime linker works on Solaris, but it should
probably already have libz somewhere in it's path. On Linux, it
used to be there was an ld.so configuration file, but that's even
obsoleted these days. To my mind, runtime dependencies outside the
control of GRASS would be difficult to handle for all of the
target platforms. Perhaps another Solaris user can comment further.

I also ran into the problem of the display/d.mon stuff getting built
with inconsistent references to sockets and fifos. Specified
--with-fifo and everything worked fine. As someone else had noted,
the compile goes fine without saying --with-fifo; it's only at
runtime that the problem arises.

There have been some recent changes with the socket handling. Could
you elaborate what the problems are? Sockets are now created in
/tmp/grass-$USER/, and it's my understanding that Solaris uses a
ramdisk for /tmp. Could there be some problem creating sockets
there? I shouldn't think so...? Perhaps there's a problem with
the username lookup? I was trying to find a solution that worked
for everyone (considering network file systems).

You can get inconsistent builds if you specify one or the other of
"--with-fifo" or "--with-socket", reconfigure with the other, and
rebuild without having done a full "distclean"...

--
Eric G. Miller <egm2@jps.net>

At 10:06 PM -0700 10/18/01, Eric G. Miller wrote:

On Thu, 18 Oct 2001 21:06:17 -0700, Hal Mueller <hal@seanet.com> wrote:

> The key is that if --with-zlib-libs=DIR is specified to
> "configure", then that directory has to end up in the
> LD_LIBRARY_PATH. I don't know where in the build tree that change
> should be made, however.

I don't know how the runtime linker works on Solaris, but it should
probably already have libz somewhere in it's path. On Linux, it
used to be there was an ld.so configuration file, but that's even
obsoleted these days. To my mind, runtime dependencies outside the
control of GRASS would be difficult to handle for all of the
target platforms. Perhaps another Solaris user can comment further.

Can't expect to handle all the runtime idiosyncrasies, but if a specific location is specified for a library on the configure command line, using a very specific configure switch, then routines that use that library should be told where to find it. That was the case with "set_data" and Init.sh--the setup for set_data didn't list the location for the libraries.

I just took another look, and there is no libz in /usr/lib. /usr/local/lib is where my installation of gcc put its libz.

> I also ran into the problem of the display/d.mon stuff getting built
> with inconsistent references to sockets and fifos. Specified
> --with-fifo and everything worked fine. As someone else had noted,
> the compile goes fine without saying --with-fifo; it's only at
> runtime that the problem arises.

There have been some recent changes with the socket handling. Could
you elaborate what the problems are? Sockets are now created in
/tmp/grass-$USER/, and it's my understanding that Solaris uses a
ramdisk for /tmp. Could there be some problem creating sockets
there? I shouldn't think so...? Perhaps there's a problem with
the username lookup? I was trying to find a solution that worked
for everyone (considering network file systems).

You can get inconsistent builds if you specify one or the other of
"--with-fifo" or "--with-socket", reconfigure with the other, and
rebuild without having done a full "distclean"...

Rats, can't find the reference now. I was getting an error when starting d.mon, don't remember the exact text. I looked up the text and "grass solaris" on Google, and found an archived email discussion. I believe that I (and also the original poster) had compiled d.mon to use sockets but had Grass configured to use fifos.

I got there by not specifying --with-fifo or --with-socket; I didn't notice the instruction to choose one or the other, and the build defaults were inconsistent. As soon as I said --with-fifo the problem went away. I didn't ever try --with-socket. Not a socket problem, but a config problem.

Hal