1. Translator
- Posted by peterR May 19, 2016
- 1666 views
Hi all Having trouble with the translator. I know it seems unlikely, but is it possible that there is an error in the translator as follows: After translation, it calls the C compiler with the -i switch and specifies EUDIR instead of EUINC (as set in eu.conf). I keep getting a message that it can't find the include file which it states to be my EUDIR file, but my configuration seems correct. I've set the -com setting in eu.conf and the include directory does include euphoria.h, so I can't figure out what's wrong. PeterR
2. Re: Translator
- Posted by peterR May 21, 2016
- 1590 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.
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?
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". Unless the library is in the $PATH then it returns a negative, 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 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
3. Re: Translator
- Posted by peterR May 21, 2016
- 1569 views
Actually, just occurred to me that the translation seems to work, but not the compilation, so the logical default directory is the same place as the build PeterR
4. Re: Translator
- Posted by jimcbrown (admin) May 21, 2016
- 1566 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.
5. Re: Translator
- Posted by peterR May 21, 2016
- 1518 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. Your comment:
"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."
Yep, I misunderstood that - but 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.
Your comment:
"Are you using a BSD or something? On GNU/Linux, it opens "" (that's right, it opens an empty string), not "libc.so"."
Sorry, I was reading the UNIX line, not realising that there was a separate LINUX line somewhere above it. (I was reading backwards from the function, which probably explains a lot about my thinking in general.)
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."
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.
Sorry to be so lengthy, but, apart from my curiosity, I thought it's good to keep up a bit of discussion on the forum. The difficulties in getting OE to work out of the box have often been mentioned on the forum, and despite my best efforts, I've had some hurdles, and they're not over yet. This originally arose out of the failure of Ken Rhodes' Eugeany and EuHelp files to compile, and now that I've got Eugeany compiling and running, it seems to be re-directing standard output, not just standard error, which is what I thought it did. So when I run Hello World! from eui it works, but when I run it from Eugeany it runs but the console is blank apart from an exit message. Ah well, guess that will be a future discussion thread.
Cheers
PeterR
6. Re: Translator
- Posted by jimcbrown (admin) May 21, 2016
- 1516 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
7. Re: Translator
- Posted by peterR May 22, 2016
- 1495 views
Re libc.so, yes, it's in /usr/lib64, and it isn't just a link. It's identified as a shared library, and I can't see any other versions there. However, on close inspection, it seemed small so I opened it in gedit and found this:
/* GNU ld script Use the shared library, but some functions are only in the static library, so try that secondarily. */
OUTPUT_FORMAT(elf64-x86-64)
GROUP ( /lib64/libc.so.6 /usr/lib64/libc_nonshared.a AS_NEEDED ( /lib64/ld-linux-x86-64.so.2 ) )
Not sure what that all means, but open_dll() is not impressed. It seems the other version is in /lib64.
Cheers
PeterR
8. Re: Translator
- Posted by jimcbrown (admin) May 22, 2016
- 1524 views
Re libc.so, yes, it's in /usr/lib64, and it isn't just a link. It's identified as a shared library, and I can't see any other versions there. However, on close inspection, it seemed small so I opened it in gedit and found this:
/* GNU ld script Use the shared library, but some functions are only in the static library, so try that secondarily. */
OUTPUT_FORMAT(elf64-x86-64)
GROUP ( /lib64/libc.so.6 /usr/lib64/libc_nonshared.a AS_NEEDED ( /lib64/ld-linux-x86-64.so.2 ) )
Not sure what that all means, but open_dll() is not impressed. It seems the other version is in /lib64.
Cheers
PeterR
Ah, that's just the standard linker script. See and http://stackoverflow.com/questions/5582688/how-is-usr-lib64-libc-so-generated
That's used at link time to link in -lc (the C library), but at run-time the linker only uses libc.so.6 (and thus doesn't need to understand the libc.so script).
