On Thu, 10 Mar 2022, Ignacio Diaz-Emparanza wrote:
El 4/3/22 a las 0:00, gretl-devel-request(a)gretlml.univpm.it
escribió:
> On Tue, 1 Mar 2022, Allin Cottrell wrote:
>
>> I think I see what's happening. On my system I have the environment
>> variable R_HOME set to "/opt/R/lib64/R". I guess in your case that
>> variable is not set. So I suspect the following: if you pass the actual
>> path to libR.so, gretl can infer where R_HOME is and all is OK. If you
>> pass a symlink and R_HOME is NOT set, R doesn't know where its files are
>> and gretl can't help.
>>
>> Anyway, it seems clear that the crash is in libR.so, which can't find
>> "Renviron" under the stated conditions: called via symlink with R_HOME
>> undefined. Maybe gretl could help with some fancy footwork, using the OS
>> to resolve a libR symlink.
>
> That "fancy footwork" is now in git. We detect the case where the
> user-specified path to libR.so is a symlink; resolve the symlink to find
> the "real" path to libR.so; use that path to figure out where
> R_HOME is; and put the correct value of R_HOME into the environment so that
> libR can find the files without which it will crash.
>
> I tested this on Fedora Linux, after removing R_HOME from my environment
> and replacing the "real" libR location in my gretl Preferences with the
> path to a symlink in /usr/local/lib.
>
> Allin
I am very sorry for this delay. I was able to check it today and it doesn't
work. I updated gretl from git, changed the path as it was originally
(/usr/lib/libR.so), but still get the same crash.
If someone could give me the exact steps to run gretl with "gdb" I can try to
do it.
Thanks, Ignacio. Here are the steps:
1) Call gdb with argument the path to the gretl executable, as in
gdb /usr/bin/gretl_x11
2) Use the "set args" command within gdb to specify a script to run,
as in
(gdb) set args /path/to/script.inp
3) Call the "run" command in gdb:
(gdb) run
You should now see some spew from gdb, presumably terminating with a
crash in the case under discussion. Then
4) Use gdb's "bt" command to get a backtrace:
(gdb) bt
This should give us some idea of where the problem lies.
Allin