Re: gretl crash
by Ignacio Diaz-Emparanza
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.
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.
Departamento de Métodos Cuantitativos
Universidad del País Vasco - Euskalherriko Unibertsitatea, UPV/EHU
Tfno: (+34) 94 601 3732