Re: Translator
- Posted by jimcbrown (admin) May 21, 2016
- 1398 views
Thanks Jim Your suggestion of changing the tildes worked. I changed them in the $PATH and in eu.cfg, so I'm not sure where that issue lay.
Glad to help.
I am curious. The translator is actually running the code, so it is looking for its own path. Can't a process return its absolute path? I think it's possible to do that in C and you wouldn't need to test that the path exists or guess at a default.
Yes, it is able to do this. Not sure why this isn't the default....
Of course, it is possible that someone would still want to override this value (such as using an older translator to work around a regression/bug but using a newer runtime library), which is why EUCOMPILEDIR exists.
In relation to paths for libraries, I had a hunch that they weren't necessary, but I interpreted this part of the manual on open_dll() as suggesting otherwise:
"file_name can be a relative or an absolute file name. Most operating systems will use the normal search path for locating non-relative files."
It's refering to the normal process for loading shared objects - that is, LD_LIBRARY_PATH and /etc/ld.so.conf - not $PATH
I also tested open_dll( "libc.so" ) on my machine and it returned zero, which seemed to confirm that there was a path issue. Does that accord with what you would expect when libc.so is in the standard lib64 directory? This was also why I thought the runtime error was inappropriate, but of course that was based on the misconception that the code tries to open libc.so.
Do you have a libc.so? On GNU/Linux I've only seen libc.so.5 and libc.so.6 but not libc.so
