Thu, Jun 20 2002
06:13:02
|
|
Request created by guest
|
|
Subject: crash on startup unless Init.sh hand-modified
Platform: Solaris2.X/Sparc
grass obtained from: CVS
grass binary for platform: Compiled from Sources
GRASS Version: pre4,also CVS branch updated 20020619
Please enter error description here (and your name)
[present in 5.0pre4 and in the CVS development branch]
On startup, the "grass5" script crashes with the cryptic message
"ld.so.1: /usr/local/grass5pre4/grass5/etc/set_data: fatal: libz.so: open failed:
No such file or directory
Killed"
Upon investigation, determined that it's while trying to sh "Init.sh". Inside
"Init.sh" there's a call to set_data, which depends on proper setting of LD_LIBRARY_PATH
to locate the dependency libraries (zlib, X Windows, fftw, etc)
Adding /usr/lib:/usr/local/lib:/usr/openwin/lib to the LD_LIBRARY_PATH in Init.sh
solves the problem. But I think the right fix is to modify Init.sh's source
file, src/general/init/init.sh, to include the locations of the subordinate libraries,
at least on Solaris. Those library locations are available in the config script.
This is another one that's trivial to fix once you know the answer, but would
be maddening to track down if you're a first-time Grass user. Most people will
simply conclude "Grass DFW".
Non-defaults: no ODBC or Postgres, included FFTW, GDAL, TCL/TK
Hal Mueller
|
|
Thu, Jun 20 2002
16:47:45
|
|
Mail sent by glynn.clements@virgin.net
|
|
Return-Path |
<glynn.clements@virgin.net>
|
Delivered-To |
grass-bugs@lists.intevation.de
|
From |
Glynn Clements <glynn.clements@virgin.net>
|
MIME-Version |
1.0
|
Content-Type |
text/plain; charset=us-ascii
|
Content-Transfer-Encoding |
7bit
|
Message-ID |
<15633.59959.89535.519177@cerise.nosuchdomain.co.uk>
|
Date |
Thu, 20 Jun 2002 15:44:07 +0100
|
To |
Request Tracker <grass-bugs@intevation.de>
|
Cc |
grass5@grass.itc.it
|
Subject |
Re: [GRASS5] [bug #1127] (grass) crash on startup unless Init.sh hand-modified
|
In-Reply-To |
<20020620041302.E1ADA13A18@lists.intevation.de>
|
References |
<20020620041302.E1ADA13A18@lists.intevation.de>
|
X-Mailer |
VM 6.94 under 21.4 (patch 4) "Artificial Intelligence (candidate #1)" XEmacs Lucid
|
X-Spam-Status |
No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20
|
X-Spam-Level |
|
Request Tracker wrote:
> this bug's URL: http://intevation.de/rt/webrt?serial_num=1127
> -------------------------------------------------------------------------
>
> Subject: crash on startup unless Init.sh hand-modified
>
> Platform: Solaris2.X/Sparc
> grass obtained from: CVS
> grass binary for platform: Compiled from Sources
> GRASS Version: pre4,also CVS branch updated 20020619
>
> Please enter error description here (and your name)
>
> [present in 5.0pre4 and in the CVS development branch]
>
> On startup, the "grass5" script crashes with the cryptic message
> "ld.so.1: /usr/local/grass5pre4/grass5/etc/set_data: fatal: libz.so: open failed:
No such file or directory
> Killed"
>
> Upon investigation, determined that it's while trying to sh "Init.sh".
> Inside "Init.sh" there's a call to set_data, which depends on proper
> setting of LD_LIBRARY_PATH to locate the dependency libraries (zlib, X
> Windows, fftw, etc)
>
> Adding /usr/lib:/usr/local/lib:/usr/openwin/lib to the LD_LIBRARY_PATH
> in Init.sh solves the problem. But I think the right fix is to modify
> Init.sh's source file, src/general/init/init.sh, to include the
> locations of the subordinate libraries, at least on Solaris.
The "right" fix is to install zlib correctly. E.g. any of:
1. Put libz.so.1 in a standard directory, where the loader will find
it; on Linux, this requires re-building the loader's cache file with
ldconfig (I don't know about Solaris, but Linux' shared library
handling is heavily based upon Solaris).
2. Put libz.so.1 somewhere else, and modify the loader configuration
(e.g. modify ld.so.conf and run ldconfig, or set LD_LIBRARY_PATH in
/etc/profile).
3. Build a static library instead of a shared library, eliminating
loader issues altogether.
Anything that GRASS can do is a workaround. Shared library workarounds
tend to be highly platform-specific, and usually involve guesswork.
There are many other programs which use libz, and most of those don't
have a startup script which can fix the loader configuration.
> Those library locations are available in the config script.
No they aren't.
The --with-*-libs options which are passed to the configure script
indicate the directories in which the linker should look. They don't
necessarily correspond to the directories which the loader should be
using; particularly:
1. When the result is intended to be installed on systems other than
the one on which GRASS was built (even more so if cross-compiling).
2. On systems which have separate "stub" libraries for linking
against.
--
Glynn Clements <glynn.clements@virgin.net>
|
|
Thu, Jun 20 2002
17:03:47
|
|
Status changed to resolved by gclements
|
|
Thu, Jun 20 2002
19:50:40
|
|
Mail sent by hal@mobilegeographics.com
|
|
Return-Path |
<hal@mobilegeographics.com>
|
Delivered-To |
grass-bugs@lists.intevation.de
|
Mime-Version |
1.0
|
X-Sender |
hal@mail.mobilegeographics.com
|
Message-Id |
<v04210102b937c5d0bbe2@[192.168.204.104]>
|
In-Reply-To |
<15633.59959.89535.519177@cerise.nosuchdomain.co.uk>
|
References |
<20020620041302.E1ADA13A18@lists.intevation.de> <15633.59959.89535.519177@cerise.nosuchdomain.co.uk>
|
Date |
Thu, 20 Jun 2002 10:50:13 -0700
|
To |
Glynn Clements <glynn.clements@virgin.net>
|
From |
Hal Mueller <hal@mobilegeographics.com>
|
Subject |
Re: [GRASS5] [bug #1127] (grass) crash on startup unless Init.sh hand-modified
|
Cc |
Request Tracker <grass-bugs@intevation.de>, grass5@grass.itc.it
|
Content-Type |
text/plain; charset="us-ascii" ; format="flowed"
|
X-Spam-Status |
No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20
|
X-Spam-Level |
|
Just so this gets into the archives--
All my libraries are in "standard" places (/usr/lib, /usr/local/lib).
However, the nonstandard thing I was doing (which was causing the
launch failure) was not having a setting for LD_LIBRARY_PATH at all
(which I had done to work around another vendor's installation
quirks). So my proposed solution was way off base. Once I added a
LD_LIBRARY_PATH the default Init.sh works fine.
H
|
|
Thu, Jun 20 2002
19:50:40
|
|
Status changed to open by _rt_system
|
|
Tue, Jul 16 2002
18:29:24
|
|
Status changed to resolved by gclements
|
|