Post by John E. Malmberg Post by John E. Malmberg Post by Richard Levitte
it's been long since I've been present here... been all busy with
OpenSSL, not much time for something else.
Post by Richard Levitte
$ cc humpf.c
%CC-F-NOINCLFILEF, Cannot find file "../something.h" specified in #include directive.
at line number 1 in file USER:[LEVITTE.TEST.CC-INCL-2.INCL]h.h;1
So my question is, is there any trick that I can do with the compiler
to make this go through without error? i would rather not have to
restructure the inclusion if I can.
Only solution that I have found is to run a pre-build script to find and
re-edit the source code to change "../" to path or a logical name.
I don't thing that is ever going to get fixed in the Alpha/IA64 compilers.
I doubt the compilers are at fault. At somepoint, we give that filespec to the CRTL's open/fopen.
Relative filespecs are controlled by various DECC$ feature logicals <insert ugly comment here>.
DECC$POSIX_COMPLIANT_PATHNAMES might help but setting that the DCL prompt before the
compilation might be too big of a hammer as some code <insert 2nd ugly comment here>.
I have the same issue with some of the files in LLVM that use relative filespecs.
The C compiler seems to isolate it self, and ignores most of the DECC$
feature logical settings that I have tried.
I will have to add some tests to gnulib-assist to see if I can duplicate
the exact problem, but for that I need to know what exactly the
compilers are passing to the CRTL.
By itself, the CRTL seems to handle most of the the "../" cases for path
to a filename.
The compiler however is doing some extra stuff with processing the
directory found in a header file depending on the options set for the
compiler on the command line (And possibly #pragmas)
And I have demonstrated that the Compiler handling of filenames is
different than the CRTL in that the <net/xxxx.h> headers in the text
library can not be accessed by the compiler if decnet is running.
The CRTL does does not have a issue with converting "net/xxx.h" to
[.net]xxx.h for finding files. Only the C Compiler treats "net/xxx.h"
as net:xxx.h and then fails the compile, very similar to the ".." failure.
If the directory is present in the specification and is a logical name,
that logical name is used. CRTL feature settings do not appear to
affect this for the C compiler, but do affect it for user programs.
Depending on the compiler settings, if a directory is present in the
specification and exists in the source code, then the header will be
used from that directory instead of the OpenVMS text libraries, except
if the directory is specified as "..".
The case of ".." is a case where this does not work, and I can not
reproduce this failure with just test programs on the CRTL, regardless
of the feature settings.
If the directory is present and is not ".." and does not exist, it
discards it and uses the OpenVMS text libraries for the headers. This
has turned out to be a very useful feature to insure that my code
includes the OpenVMS header file instead of a file with the same name
used by a project. (Pretty common in open source porting)
Either way the current behavior of the compiler is incorrect. If it is
in the CRTL, then it is bug and should get fixed there, otherwise it
should get fixed or worked around in the compiler, just like the
handling of the decnet NET: device needs to get fixed in the compiler.
I know. There is some GEM code mixed in as well. I don't see the C compiler (or
the C++) compiler doing anything to avoid DECC$ logicals. For example, turn on