First test:
echo $LD_LIBRARY_PATH
/usr/local/grass5.7.cvs-i686-pc-linux-gnu-25_11_2004/lib
...looks ok. Ans this directory contains the libs.
I found out so far:
- d.zoom on CMD line works;
- d.m/d.zoom (icon) fails: for microseconds the requested terminal
is opened, then it closes. no error message.
Looking into the code, I found that in effect next line is executed
in the display manager:
xterm -e d.zoom
Running this command on command line provides the same undesired
behaviour (immediate closing of xterm after launching).
Interestingly, when running
strace xterm -e d.zoom
it works!
On Tue, 30 Nov 2004 18:12:33 +0100 Markus Neteler <neteler@itc.it>
wrote:
Any suggestions how to proceed? Maybe the xterm doesn't work as
desired under Debian (why does it then with strace)?
Maybe it is a security reason, because xtrem has the s bit set. I am not
quite sure about that, but isnt it that $LD_LIBRARY_PATH is unloaded
for s-bittet programms?!
It seems a quite reasonable explanation.
Could anybody suggest a clean solution?
pc
At 07:57, mercoledì 01 dicembre 2004, Stephan Holl has probably written:
Hello Markus,
On Tue, 30 Nov 2004 18:12:33 +0100 Markus Neteler <neteler@itc.it>
wrote:
> Any suggestions how to proceed? Maybe the xterm doesn't work as
> desired under Debian (why does it then with strace)?
Maybe it is a security reason, because xtrem has the s bit set. I am not
quite sure about that, but isnt it that $LD_LIBRARY_PATH is unloaded
for s-bittet programms?!
On Wed, Dec 01, 2004 at 07:57:10AM +0100, Stephan Holl wrote:
Hello Markus,
On Tue, 30 Nov 2004 18:12:33 +0100 Markus Neteler <neteler@itc.it>
wrote:
> Any suggestions how to proceed? Maybe the xterm doesn't work as
> desired under Debian (why does it then with strace)?
Maybe it is a security reason, because xtrem has the s bit set. I am not
quite sure about that, but isnt it that $LD_LIBRARY_PATH is unloaded
for s-bittet programms?!
> > Any suggestions how to proceed? Maybe the xterm doesn't work as
> > desired under Debian (why does it then with strace)?
>
> Maybe it is a security reason, because xtrem has the s bit set. I am not
> quite sure about that, but isnt it that $LD_LIBRARY_PATH is unloaded
> for s-bittet programms?!
>
>
> See former posting from Glynn Clements on a similar problem:
> http://grass.itc.it/pipermail/grass5/2004-September/015409.html
OK, now in CVS:
grass57/tools/grass-run.sh
This should go elsewhere, e.g. lib/init. AIUI, the tools directory is
meant for things which aren't installed, e.g. tools for building or
maintaining GRASS rather than for using it.
BTW, we shouldn't need tools/getModtime any more; man/Makefile has
been fixed to use make's built in functionality instead.
Tcl doesn't have "global" variables like most languages. It has
"top-level" variables, but these aren't normally visible within
procedures. You need to use "global" to make it visible, i.e.:
proc term {cmd args} {
global env
eval exec -- xterm -e $env(GISBASE)/etc/grass-run.sh $cmd $args &
}
On Wed, Dec 01, 2004 at 10:40:28AM +0000, Glynn Clements wrote:
Markus Neteler wrote:
> > > Any suggestions how to proceed? Maybe the xterm doesn't work as
> > > desired under Debian (why does it then with strace)?
> >
> > Maybe it is a security reason, because xtrem has the s bit set. I am not
> > quite sure about that, but isnt it that $LD_LIBRARY_PATH is unloaded
> > for s-bittet programms?!
> >
> >
> > See former posting from Glynn Clements on a similar problem:
> > http://grass.itc.it/pipermail/grass5/2004-September/015409.html
>
> OK, now in CVS:
>
> grass57/tools/grass-run.sh
This should go elsewhere, e.g. lib/init. AIUI, the tools directory is
meant for things which aren't installed, e.g. tools for building or
maintaining GRASS rather than for using it.
OK, moved to lib/init/.
BTW, we shouldn't need tools/getModtime any more; man/Makefile has
been fixed to use make's built in functionality instead.
Removed in CVS.
> Howver, the proposed xterm line causes problems:
>
> can't read "env(GISBASE)": no such variable
>
> Not sure how to implement it correctly:
>
> diff -u -r1.27 d.m.tcl
> --- d.m.tcl 14 Sep 2004 16:48:38 -0000 1.27
> +++ d.m.tcl 1 Dec 2004 09:00:14 -0000
> @@ -85,7 +85,7 @@
>
> ###############################################################################
> proc term {cmd args} {
> - eval exec -- xterm -e $cmd $args &
> + eval exec -- xterm -e $env(GISBASE)/etc/grass-run.sh $cmd $args &
> }
Tcl doesn't have "global" variables like most languages. It has
"top-level" variables, but these aren't normally visible within
procedures. You need to use "global" to make it visible, i.e.:
proc term {cmd args} {
global env
eval exec -- xterm -e $env(GISBASE)/etc/grass-run.sh $cmd $args &
}
Thanks.
d.m is now updated in CVS.
Debian users: please try again (don't forget to revert the /etc/ld.so.conf change
for testing, run ldconfig as well).
I had to modify lib/init/grass-run.sh to make it working for Fedora:
Well in general it looks like it should just be passing on the current LD_LIBRARY_PATH (whatever that contains). Would something like
exec xterm -e LD_LIBRARY_PATH=$env(LD_LIBRARY_PATH) d.zoom
(in the Tcl code) not work?
And there is also the problem (noted in Glynn's original e-mail) that e.g. LD_LIBRARY_PATH is called different things on different platforms, e.g. DYLD_LIBRARY_PATH on OS X. But this can be fixed by dynamically substituting the correct variable name in at compile-time like is done for lib/init/init.sh
On Wed, Dec 01, 2004 at 01:18:59PM +0000, Paul Kelly wrote:
On Wed, 1 Dec 2004, Markus Neteler wrote:
[...]
>d.m is now updated in CVS.
>Debian users: please try again (don't forget to revert the /etc/ld.so.conf
>change
>for testing, run ldconfig as well).
>
>I had to modify lib/init/grass-run.sh to make it working for Fedora:
>
>LD_LIBRARY_PATH=$LD_LIBRARY_PATH:"$GISBASE/lib"
> ^^^^^^^^^^^^^^^^^-added
>
>Hopefully this problem is resolved now.
Well in general it looks like it should just be passing on the current
LD_LIBRARY_PATH (whatever that contains). Would something like
exec xterm -e LD_LIBRARY_PATH=$env(LD_LIBRARY_PATH) d.zoom
(in the Tcl code) not work?
And there is also the problem (noted in Glynn's original e-mail) that e.g.
LD_LIBRARY_PATH is called different things on different platforms, e.g.
DYLD_LIBRARY_PATH on OS X. But this can be fixed by dynamically
substituting the correct variable name in at compile-time like is done for
lib/init/init.sh
Paul
[isn't it easier to handle such necessary conditions in grass-run.sh
rather than messing up d.m.tcl? ]
Please submit further changes directly to CVS (I would like to
leave this problem to more skilled programmers than me
Well in general it looks like it should just be passing on the current
LD_LIBRARY_PATH (whatever that contains). Would something like
exec xterm -e LD_LIBRARY_PATH=$env(LD_LIBRARY_PATH) d.zoom
(in the Tcl code) not work?
And there is also the problem (noted in Glynn's original e-mail) that e.g.
LD_LIBRARY_PATH is called different things on different platforms, e.g.
DYLD_LIBRARY_PATH on OS X. But this can be fixed by dynamically
substituting the correct variable name in at compile-time like is done for
lib/init/init.sh
Paul
[isn't it easier to handle such necessary conditions in grass-run.sh
rather than messing up d.m.tcl? ]
The thing is we are assuming LD_LIBRARY_PATH has been unset by the time grass-run.sh is run, and we need to set it again. So your change doesn't really make sense as on the systems that have the problem, $LD_LIBRARY_PATH will already be empty by that stage. I was thinking if we need to pass on an already existing LD_LIBRARY_PATH, it needs to be evaluated before xterm is run as that is what unsets it.
I'm not sure enough to make a change, just want to add to the discussion and have it documented!
On Wed, Dec 01, 2004 at 01:31:16PM +0000, Paul Kelly wrote:
On Wed, 1 Dec 2004, Markus Neteler wrote:
>On Wed, Dec 01, 2004 at 01:18:59PM +0000, Paul Kelly wrote:
>>On Wed, 1 Dec 2004, Markus Neteler wrote:
>>
>>[...]
>>>d.m is now updated in CVS.
>>>Debian users: please try again (don't forget to revert the
>>>/etc/ld.so.conf
>>>change
>>>for testing, run ldconfig as well).
>>>
>>>I had to modify lib/init/grass-run.sh to make it working for Fedora:
>>>
>>>LD_LIBRARY_PATH=$LD_LIBRARY_PATH:"$GISBASE/lib"
>>> ^^^^^^^^^^^^^^^^^-added
>>>
>>>Hopefully this problem is resolved now.
>>
>>Well in general it looks like it should just be passing on the current
>>LD_LIBRARY_PATH (whatever that contains). Would something like
>>exec xterm -e LD_LIBRARY_PATH=$env(LD_LIBRARY_PATH) d.zoom
>>(in the Tcl code) not work?
>>
>>And there is also the problem (noted in Glynn's original e-mail) that e.g.
>>LD_LIBRARY_PATH is called different things on different platforms, e.g.
>>DYLD_LIBRARY_PATH on OS X. But this can be fixed by dynamically
>>substituting the correct variable name in at compile-time like is done for
>>lib/init/init.sh
>>
>>Paul
>
>[isn't it easier to handle such necessary conditions in grass-run.sh
>rather than messing up d.m.tcl? ]
The thing is we are assuming LD_LIBRARY_PATH has been unset by the time
grass-run.sh is run, and we need to set it again. So your change doesn't
really make sense as on the systems that have the problem,
$LD_LIBRARY_PATH will already be empty by that stage. I was thinking if we
need to pass on an already existing LD_LIBRARY_PATH, it needs to be
evaluated before xterm is run as that is what unsets it.
I simply took the proposed suggestion to make things happen (it was
suggested month ago).
I'm not sure enough to make a change, just want to add to the discussion
and have it documented!
>> [...]
>>> I had to modify lib/init/grass-run.sh to make it working for Fedora:
>>>
>>> LD_LIBRARY_PATH=$LD_LIBRARY_PATH:"$GISBASE/lib"
>>> ^^^^^^^^^^^^^^^^^-added
>>>
>>> Hopefully this problem is resolved now.
>>
>> Well in general it looks like it should just be passing on the
>current LD_LIBRARY_PATH (whatever that contains). Would something
>like exec xterm -e LD_LIBRARY_PATH=$env(LD_LIBRARY_PATH) d.zoom
>> (in the Tcl code) not work?
..
The thing is we are assuming LD_LIBRARY_PATH has been unset by the
time grass-run.sh is run, and we need to set it again. So your change
doesn't really make sense as on the systems that have the problem,
$LD_LIBRARY_PATH will already be empty by that stage. I was thinking
if we need to pass on an already existing LD_LIBRARY_PATH, it needs to
be evaluated before xterm is run as that is what unsets it.
if [ -z LD_LIBRARY_PATH ] ; then
LD_LIBRARY_PATH="$GISBASE/lib"
else
LD_LIBRARY_PATH="$LD_LIBRARY_PATH":"$GISBASE/lib"
fi
export LD_LIBRARY_PATH
q: should order be "$LD_LIBRARY_PATH":"$GISBASE/lib" or
"$GISBASE/lib":"$LD_LIBRARY_PATH"?
> d.m is now updated in CVS.
> Debian users: please try again (don't forget to revert the /etc/ld.so.conf change
> for testing, run ldconfig as well).
>
> I had to modify lib/init/grass-run.sh to make it working for Fedora:
>
> LD_LIBRARY_PATH=$LD_LIBRARY_PATH:"$GISBASE/lib"
> ^^^^^^^^^^^^^^^^^-added
>
> Hopefully this problem is resolved now.
Well in general it looks like it should just be passing on the current
LD_LIBRARY_PATH (whatever that contains). Would something like
exec xterm -e LD_LIBRARY_PATH=$env(LD_LIBRARY_PATH) d.zoom
(in the Tcl code) not work?
No. Neither Tcl's "exec" command nor xterm's -e switch use the shell,
so you can't use shell syntax. You could use e.g.
exec xterm -e /bin/sh -c $command
but that creates problems of its own (e.g. if the ultimate command
includes arguments which need to be quoted to prevent shell
substitutions etc).
And there is also the problem (noted in Glynn's original e-mail) that e.g.
LD_LIBRARY_PATH is called different things on different platforms, e.g.
DYLD_LIBRARY_PATH on OS X. But this can be fixed by dynamically
substituting the correct variable name in at compile-time like is done for
lib/init/init.sh
> And there is also the problem (noted in Glynn's original e-mail) that e.g.
> LD_LIBRARY_PATH is called different things on different platforms, e.g.
> DYLD_LIBRARY_PATH on OS X. But this can be fixed by dynamically
> substituting the correct variable name in at compile-time like is done for
> lib/init/init.sh
[isn't it easier to handle such necessary conditions in grass-run.sh
rather than messing up d.m.tcl? ]
Yes. The LD_LIBRARY_PATH_VAR substitution should be performed on
grass-run.sh.
The thing is we are assuming LD_LIBRARY_PATH has been unset by the time
grass-run.sh is run, and we need to set it again. So your change doesn't
really make sense as on the systems that have the problem,
$LD_LIBRARY_PATH will already be empty by that stage.
xterm isn't guaranteed to be setuid/setgid; it isn't on my system
(Gentoo). Consequently, you don't know whether LD_LIBRARY_PATH will
have been re-set in xterm.
Historically, it needed to be setuid root to set the ownership of the
pty and to update the utmp/wtmp files. Modern versions of glibc have a
setuid-root helper program (pt_chown) to deal with the pty ownership,
and the utempter library has a similar helper to deal with the
utmp/wtmp files.
I was thinking if we
need to pass on an already existing LD_LIBRARY_PATH, it needs to be
evaluated before xterm is run as that is what unsets it.
Yes. One option would be to copy it to a separate variable, e.g.:
set env(saved_lib_path) $env(LD_LIBRARY_PATH)
exec xterm -e ...
and have grass-run.sh restore it from that. Although that requires the
Tcl/Tk code to know about the platform-specific variable names.
Another option would be to dump the entire environment to a file and
have grass-run.sh restore it.
I was thinking if we
need to pass on an already existing LD_LIBRARY_PATH, it needs to be
evaluated before xterm is run as that is what unsets it.
Yes. One option would be to copy it to a separate variable, e.g.:
set env(saved_lib_path) $env(LD_LIBRARY_PATH)
exec xterm -e ...
and have grass-run.sh restore it from that. Although that requires the
Tcl/Tk code to know about the platform-specific variable names.
Another option would be to dump the entire environment to a file and
have grass-run.sh restore it.
Well as I understand it everything else will be preserved: it is just LD_LIBRARY_PATH that is unset; is that right?
What about just setting another variable in Init.sh? After the correct LD_LIBRARY_PATH for the GRASS session has been determined and set,
copy it also to GRASS_LD_LIBRARY_PATH. That wouldn't be unset by xterm and
then it could be restored to LD_LIBRARY_PATH in the script. Although I
suppose if the user changed their LD_LIBRARY_PATH after starting the GRASS session something might be missing, but that would probably be quite unlikely.
>> I was thinking if we
>> need to pass on an already existing LD_LIBRARY_PATH, it needs to be
>> evaluated before xterm is run as that is what unsets it.
>
> Yes. One option would be to copy it to a separate variable, e.g.:
>
> set env(saved_lib_path) $env(LD_LIBRARY_PATH)
> exec xterm -e ...
>
> and have grass-run.sh restore it from that. Although that requires the
> Tcl/Tk code to know about the platform-specific variable names.
>
> Another option would be to dump the entire environment to a file and
> have grass-run.sh restore it.
Well as I understand it everything else will be preserved: it is just
LD_LIBRARY_PATH that is unset; is that right?
There are a couple of other LD_* variables which are unset, e.g.
LD_PRELOAD.
What about just setting another variable in Init.sh? After the correct
LD_LIBRARY_PATH for the GRASS session has been determined and set,
copy it also to GRASS_LD_LIBRARY_PATH. That wouldn't be unset by xterm and
then it could be restored to LD_LIBRARY_PATH in the script.
Agreed. Although this doesn't entirely solve the issue of
platform-specific variable names, it removes it from the Tcl/Tk code.
Although I
suppose if the user changed their LD_LIBRARY_PATH after starting the GRASS
session something might be missing, but that would probably be quite unlikely.
We don't need to support that. The user can always change
GRASS_LD_LIBRARY_PATH if they really need to.
