Re: Translator
- Posted by jimcbrown (admin) May 21, 2016
- 1447 views
OK, I've progressed this one a little. I think it does raise some issues.
The message received when I translate is this.
Translating code, pass: 1 2 3 4 5 6 7 8 9 10 11 generating
Couldn't get include directory '/euphoria-4.10-Linux-x64'
I've tracked this down to buildsys.e, lines 465-469 in the source, which calls get_eucompiledir() in c_decl.e, line 132.
The first thing to note is that the error message seems wrong, because the function is not looking for the include directory, it's looking for the compile directory.
Agreed. Someone should file a ticket about this.
The function get_eucompiledir() looks for a compile directory in a number of places and then settles by default on the EUDIR, which is what is appearing in the error message. This raises the question of whether this is the appropriate default. Wouldn't the current directory make more sense for a build?
Well, no. It's looking for where the translator is installed (so it can find eu.a and other things), not the directory where the source code is compiled from.
The file name is then tested by the function file_exists() in std/filesys.e. The trouble is that file_exists() looks for the file using a C library that is opened only by name "libc.so".
Are you using a BSD or something? On GNU/Linux, it opens "" (that's right, it opens am empty string), not "libc.so". See http://scm.openeuphoria.org/hg/euphoria/file/490db928fa10/include/std/filesys.e#l37
Unless the library is in the $PATH then it returns a negative,
No, that's not right. open_dll() calls dlopen() on GNU/Linux, which has a different search pattern independent of $PATH.
and file_exists() reports that the EUDIR doesn't exist. libc.so is on my system, but the libraries are not in the path environment variable.
It isn't necessary to have libraries (or lib directories) in $PATH.
It seems odd to create a standard function to determine the existence of a file that depends on the existence in the path of a completely different file, of which the user will have no inkling. At the very least, I'm thinking that file_exists() needs to generate a runtime error to warn the user that it has failed to find the requisite library, not the file the user is testing.
Any thoughts?
PeterR
Based on your error it obviously found the C library that it was looking for. If that call had failed, you would have seen a different run-time error about not being able to open that library (or about not being able to call a C routine).
Instead, file_exist() successfully used the C library to attempt to find your EUDIR. However, the C library is reporting that the directory doesn't exist.
It's possible that the functions we are using do not expand the tilde character into the $HOME directory. I suspect that if you instead spelled out the full path directly in $EUDIR, this would get farther.
