Re: Any progress with FIS GT.M?
> On 06/18/2012 02:42 PM, Brad King wrote:
> Here is a patch series that solves this problem. I've only done
> some lightweight/manual testing with this. The first patch
> refactors both i386 and x86_64 code paths that emit the path to
> the source file into the object file to send source file path
> lookup through a common point (in obj_source.c). The second
> patch modifies this common point to read a 'gtm_destdir' env var
> and strip the prefix it names from source file paths.
I gave brief check to Brad's patches and adjusted Debian packaging in SVN to
make use of them (but without yet placing actual patches into quilt -- I just
grabbed the HEAD of his master for the .orig "tarball"). From the first
look (dumping strings on generated .o and .so) it did exactly what I hoped them
to do -- thanks Brad! Then I have tried to run those basic commands Bhaskar
has listed but it seems that mumps doesn't even try to load libgtmutil.so to
get access to all those pre-built .o's placed into this dynamic library on my
amd64 laptop... so anything I try fails, e.g.:
novo:/tmp
$> echo $gtm_dist
/usr/lib/fis-gtm/V5.5-000+git80-g211bd16_x86_64
$> strace -fF -o /tmp/123strace2.log $gtm_dist/mumps -direct
GTM>write $text(^%RSEL)
GTM>zhelp
%GTM-E-ZLINKFILE, Error while zlinking "GTMHELP",%GTM-E-FILENOTFND, File GTMHELP not found
At M source location +1^GTM$DMOD
GTM>
$> grep libgtmutil.so /tmp/123strace2.log
$> grep open /tmp/123strace2.log | head
25537 open("tls/x86_64/libelf.so.1", O_RDONLY) = -1 ENOENT (No such file or directory)
25537 open("tls/libelf.so.1", O_RDONLY) = -1 ENOENT (No such file or directory)
25537 open("x86_64/libelf.so.1", O_RDONLY) = -1 ENOENT (No such file or directory)
25537 open("libelf.so.1", O_RDONLY) = -1 ENOENT (No such file or directory)
25537 open("/usr/local/lib/tls/x86_64/libelf.so.1", O_RDONLY) = -1 ENOENT (No such file or directory)
25537 open("/usr/local/lib/tls/libelf.so.1", O_RDONLY) = -1 ENOENT (No such file or directory)
25537 open("/usr/local/lib/x86_64/libelf.so.1", O_RDONLY) = -1 ENOENT (No such file or directory)
25537 open("/usr/local/lib/libelf.so.1", O_RDONLY) = -1 ENOENT (No such file or directory)
25537 open("/etc/ld.so.cache", O_RDONLY) = 3
25537 open("/usr/lib/libelf.so.1", O_RDONLY) = 3
might be my own screw up... or side-effect of the patch somehow
> The net diffstat of the series is:
> sr_i386/obj_file.c | 8 ++++++--
> sr_unix/comp_lits.c | 11 +++++++----
> sr_unix/obj_file.c | 10 ++++++----
> sr_unix/obj_source.c | 25 +++++++++++++++++++++++++
> sr_unix/obj_source.h | 12 ++++++++++++
> sr_unix_nsb/comp_lits.c | 11 +++++++----
> 6 files changed, 63 insertions(+), 14 deletions(-)
> I tried to follow style and portability conventions I found in
> existing sources, but this is the first time I've read the code
> so the patches may need adjustment for such things. The series
> also doesn't touch any documentation.
> [KSB2] Thank you very much, Brad.
> We would like to ask if you would be willing to solve the issue with one
> of two slightly different approaches from what you have implemented.
> * Provide an environment variable, which if set, will check whether
> $gtm_dist is a leading prefix of of the path to the source code
> module, and if so, will put $gtm_dist instead of the absolute path.
> This would allow the GT.M distribution itself to be moved in the
> course of installing a Debian package.
> * Provide an environment variable, which if set will place a relative
> path from the object code module to the source code module, rather
> than an absolute path. One wrinkle with this is that the object code
> module itself may be placed in a shared library, and if that is the
> case, the relative path will need to start from the directory in which
> the shared library resides.
> Thanks again.
> Regards
> -- Bhaskar
--
Yaroslav O. Halchenko
Postdoctoral Fellow, Department of Psychological and Brain Sciences
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419
WWW: http://www.linkedin.com/in/yarik
Reply to: