C compiler snag

[Richard Levitte]

Hey folks,

it's been long since I've been present here... been all busy with OpenSSL, not much time for something else.

Now, speaking of OpenSSL, I'm hitting an "interesting" snag that I can't seem to find a good solution for. It's easy to demonstrate, with this set of files:

humpf.c
[.incl]h.h
something.h

----- humpf.c
#include "./incl/h.h"

int main()
{
}
-----

----- [.incl]h.h
#include "../something.h"
-----

----- something.h
int foo(void);
-----

The content of those files isn't terribly interesting, but the inclusion sequence is, i.e. humpf.c includes "./incl/h.h" includes "../something.h". Structures like this may seem strange, but they do exist. So now for the snag:

-----
$ cc humpf.c

#include "../something.h"
.^
%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.

Version data:

(alpha) $ cc/version
VSI C V7.4-002 on OpenVMS Alpha V8.4-2L2

(itanium) $ cc/version
VSI C V7.4-001 on OpenVMS IA64 V8.4-2L1

[Craig A. Berry]

Have you tried specifying the current working directory in Unix format
on the command line:
cc/include="./" humpf.c

?

I think I remember something like that being necessary for some
situation, but I'm not sure if it was this situation exactly.

Other than that, SET WATCH FILE is your friend for figuring out where
exactly the compiler is looking for the file it can't find.

[Richard Whalen]

I think that you need to look at /NESTED_INCLUDE_DIRECTORY

[David Jones]

On Wednesday, May 19, 2021 at 7:57:10 AM UTC-4, Craig A. Berry wrote:

> Have you tried specifying the current working directory in Unix format
> on the command line:
> cc/include="./" humpf.c
>
> ?
>
> I think I remember something like that being necessary for some
> situation, but I'm not sure if it was this situation exactly.
>

I replicated the problem, and got it work with
cc/include="./incl" humpf.c

Specifying various values of /nest_include made no difference.

[John E. Malmberg]

On 5/19/2021 4:51 AM, Richard Levitte wrote:
> Hey folks,
>
> it's been long since I've been present here... been all busy with
> OpenSSL, not much time for something else.

<snip>

>
> -----
> $ cc humpf.c
>
> #include "../something.h"
> .^
> %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.

Regards,
-John

[John Reagan]

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.

[Simon Clubley]

On 2021-05-19, John Reagan <xyzz...@gmail.com> wrote:
> 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.

That just means you don't have enough logicals to control behaviour, John.

You just need a few more logicals for extra configuration options. :-)

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

[Richard Levitte]

onsdag 19 maj 2021 kl. 14:30:46 UTC+2 skrev rvwh...@gmail.com:

> I think that you need to look at /NESTED_INCLUDE_DIRECTORY

That defaults to INCLUDE_FILE, which seems sensible.

[Richard Levitte]

onsdag 19 maj 2021 kl. 14:46:25 UTC+2 skrev osuv...@gmail.com:
> I replicated the problem, and got it work with
> cc/include="./incl" humpf.c

Ah! That actually makes sense, albeit a bit strangely. What I understand is that with this, "../something.h" will among others get to look at "./incl/../something.h", and that will find the header file in question.

Gotta admit, though, that it's a bit annoying having to do this sort of trick...

Anyway, thanks! This does help quite a bit.

Cheers,
Richard

[Craig A. Berry]

On 5/19/21 7:46 AM, David Jones wrote:
> On Wednesday, May 19, 2021 at 7:57:10 AM UTC-4, Craig A. Berry wrote:
>
>> Have you tried specifying the current working directory in Unix format
>> on the command line:
>> cc/include="./" humpf.c

Nope, that doesn't work.

> I replicated the problem, and got it work with
> cc/include="./incl" humpf.c

That works for this made-up case but may not be general enough. It also
works because ./incl/../something.h is the same as ./something.h, and
the grandchild may not always be in the same location as the
grandparent. You could specify any subdirectory, even a nonexistent
one, and the result would be the same. For example, this works:

$ cc/include="./nosuchdir" humpf

A bit of poking with SET WATCH FILE/CLASS=ALL and DFU shows that the
first place the compiler looks for something.h when no include
directories are specified explicitly is the parent directory one level
up from where humpf.c is located. The next place it looks is relative
to the POSIX root but at that point it's already given up on finding it
relative to the program being compiled.

So the compiler is honoring the relative portion of the path, but it is
considering it relative to the grandparent .c file or the current
working directory of the compile operation (which are the same in this
case) and *not* relative to the file containing the #include directive
(h.h).

Whether this is a bug or a feature I don't know. But it is definitely
different from what other compilers do.

> Specifying various values of /nest_include made no difference.
>

P.S. DFU was necessary because SET WATCH FILE gives you only the FID,
not the name, of the directory in a "Read only directory access"
message. So you have to take a message like this:

%XQP, Thread #0, Read only directory access (15599,12,0)

and find out what it is with:

$ mcr dfu search/fid=15599 dka7:

Disk and File Utilities for OpenVMS V3.2
%DFU-I-SEARCH, Start search on DKA7: ($2$DKA7:)

$2$DKA7:[000000]PSX$ROOT.DIR;1
1/16

%DFU-I-EOF, End of file INDEXF.SYS, Primary headers : 1

%DFU-S-FND , Files found : 1, Size : 1/16

[Dave Froble]

On 5/19/2021 1:24 PM, Simon Clubley wrote:
> On 2021-05-19, John Reagan <xyzz...@gmail.com> wrote:
>> 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.
>
> That just means you don't have enough logicals to control behaviour, John.
>
> You just need a few more logicals for extra configuration options. :-)
>
> Simon.
>

Simon is now in big trouble with several people.

No, the smily isn't going to save you.

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: da...@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

[Simon Clubley]

On 2021-05-19, Dave Froble <da...@tsoft-inc.com> wrote:
> On 5/19/2021 1:24 PM, Simon Clubley wrote:
>> On 2021-05-19, John Reagan <xyzz...@gmail.com> wrote:
>>> 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.
>>
>> That just means you don't have enough logicals to control behaviour, John.
>>
>> You just need a few more logicals for extra configuration options. :-)
>>
>> Simon.
>>
>
> Simon is now in big trouble with several people.
>
> No, the smily isn't going to save you.
>

Well, it wouldn't be the first time that Simon has upset some people
around here. :-)

[Dave Froble]

On 5/19/2021 7:12 PM, Simon Clubley wrote:
> On 2021-05-19, Dave Froble <da...@tsoft-inc.com> wrote:
>> On 5/19/2021 1:24 PM, Simon Clubley wrote:
>>> On 2021-05-19, John Reagan <xyzz...@gmail.com> wrote:
>>>> 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.
>>>
>>> That just means you don't have enough logicals to control behaviour, John.
>>>
>>> You just need a few more logicals for extra configuration options. :-)
>>>
>>> Simon.
>>>
>>
>> Simon is now in big trouble with several people.
>>
>> No, the smily isn't going to save you.
>>
>
> Well, it wouldn't be the first time that Simon has upset some people
> around here. :-)

You claiming to be a troll?

:-)

[Simon Clubley]

On 2021-05-19, Dave Froble <da...@tsoft-inc.com> wrote:
> On 5/19/2021 7:12 PM, Simon Clubley wrote:
>> On 2021-05-19, Dave Froble <da...@tsoft-inc.com> wrote:
>>> On 5/19/2021 1:24 PM, Simon Clubley wrote:
>>>> On 2021-05-19, John Reagan <xyzz...@gmail.com> wrote:
>>>>> 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.
>>>>
>>>> That just means you don't have enough logicals to control behaviour, John.
>>>>
>>>> You just need a few more logicals for extra configuration options. :-)
>>>>
>>>> Simon.
>>>>
>>>
>>> Simon is now in big trouble with several people.
>>>
>>> No, the smily isn't going to save you.
>>>
>>
>> Well, it wouldn't be the first time that Simon has upset some people
>> around here. :-)
>
> You claiming to be a troll?
>
>:-)
>

No David. Just someone willing to speak some uncomfortable truths
when needed.

(However, the comment to John was a joke.)

[John E. Malmberg]

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.

The behavior that I see:

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.

Regards,
-John

[John Reagan]

I'll do more research but there is nothing of your description that matches what
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
DECC$POSIX_COMPLIANT_PATHNAMES and watch the compiler not able to find
.TLB files, etc.

[Craig A. Berry]

On 5/21/21 8:26 AM, John E. Malmberg wrote:
> 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.

You seem to have missed my analysis showing that ../ does work but the
question about handling relative paths is relative to what? As far as I
can find, there is no standard and how this is handled is
implementation-defined. Most compilers seem to specify that it's
relative to the file in which the #include directive is found. The VMS
compiler doesn't do that but looks for the header relative to either the
top-level compilation unit or the current working directory from which
the compile command was run. The two were one and the same in the
example originally posted, so it's impossible to know which without
further analysis (or reading the compiler sources, which I don't have).

[Simon Clubley]

On 2021-05-21, John Reagan <xyzz...@gmail.com> wrote:
> I'll do more research but there is nothing of your description that matches what
> 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
> DECC$POSIX_COMPLIANT_PATHNAMES and watch the compiler not able to find
> .TLB files, etc.

John is very right about this. There is a problem when you use net/
within an include statement. The following code compiles: !!!

---------------------------------------------------------------------------
$ type nettest.c
#include <stdio.h>
#include <net/does_not_exist.h>

int main(int argc, char *argv[])
{
printf("Testing net include\n");
return 0;
}
$ cc nettest.c
---------------------------------------------------------------------------

Change this to the following and you get the expected error:

---------------------------------------------------------------------------
$ type nettest.c
#include <stdio.h>
#include <net1/does_not_exist.h>

int main(int argc, char *argv[])
{
printf("Testing net include\n");
return 0;
}
$ cc nettest.c

#include <net1/does_not_exist.h>
.^
%CC-F-NOINCLFILEF, Cannot find file <net1/does_not_exist.h> specified in #includ
e directive.
---------------------------------------------------------------------------

$ cc/version
VSI C V7.4-002 on OpenVMS Alpha V8.4-2L2

[Simon Clubley]

On 2021-05-21, Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
> On 2021-05-21, John Reagan <xyzz...@gmail.com> wrote:
>> I'll do more research but there is nothing of your description that matches what
>> 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
>> DECC$POSIX_COMPLIANT_PATHNAMES and watch the compiler not able to find
>> .TLB files, etc.
>
> John is very right about this. There is a problem when you use net/
> within an include statement. The following code compiles: !!!

That is John Malmberg is right about this. Too many people called John
around here. :-)

Simon.

[Craig A. Berry]

On 5/21/21 12:42 PM, Simon Clubley wrote:
> There is a problem when you use net/
> within an include statement. The following code compiles: !!!
>
> ---------------------------------------------------------------------------
> $ type nettest.c
> #include <stdio.h>
> #include <net/does_not_exist.h>
>
> int main(int argc, char *argv[])
> {
> printf("Testing net include\n");
> return 0;
> }
> $ cc nettest.c
> ---------------------------------------------------------------------------

Bug or feature I don't know, but again it seems to have nothing to do
with the compiler. Opening a non-existent file on the net: device
returns success. What you expect from opening a non-existent file:

$ perl -e "open my $f, '<', 'nosuchfile.dat' or die $^E;"
%RMS-E-FNF, file not found at -e line 1.
%SYSTEM-F-ABORT, abort

What you get when you prepend "net:" to the filename:

$ perl -e "open my $f, '<', 'net:nosuchfile.dat' or die $^E;"
$ show symbol $status
$STATUS == "%X00000001"

Note that you can't reproduce this with DCL:

$ open f net:nosuchfile.dat
%DCL-E-INVRFM, invalid record format for record I/O - file not opened

So the compiler is just converting net/does_not_exist.h to VMS syntax
net:does_not_exist.h and getting a successful open but nothing happens
when you read from it (except EOF I guess). The filename portion
doesn't matter and seems to be ignored. As far as I can tell, the
behavior is identical to that of _NLA0:.

The compiler could also be led astray by:

#include "nl/foo.h"

[Simon Clubley]

On 2021-05-21, Craig A. Berry <craig...@nospam.mac.com> wrote:
> On 5/21/21 12:42 PM, Simon Clubley wrote:
>> There is a problem when you use net/
>> within an include statement. The following code compiles: !!!
>>
>> ---------------------------------------------------------------------------
>> $ type nettest.c
>> #include <stdio.h>
>> #include <net/does_not_exist.h>
>>
>> int main(int argc, char *argv[])
>> {
>> printf("Testing net include\n");
>> return 0;
>> }
>> $ cc nettest.c
>> ---------------------------------------------------------------------------
>
> Bug or feature I don't know, but again it seems to have nothing to do
> with the compiler. Opening a non-existent file on the net: device
> returns success. What you expect from opening a non-existent file:
>

I'm not so sure. Based on what has been said so far, I think this
is a compiler specific problem.

I think John Malmberg is right and that the compiler is wrongly
looking for a device (NET:) with the name of the net/ include directory
and using that instead of looking for a [.net] directory.

>
> So the compiler is just converting net/does_not_exist.h to VMS syntax
> net:does_not_exist.h and getting a successful open but nothing happens
> when you read from it (except EOF I guess). The filename portion
> doesn't matter and seems to be ignored. As far as I can tell, the
> behavior is identical to that of _NLA0:.
>

That's my understanding as well. What it should be doing instead is
looking for [.net]does_not_exist.h and then reporting an error when
it doesn't find the file in that location.

[Craig A. Berry]

On 5/21/21 4:13 PM, Simon Clubley wrote:
> On 2021-05-21, Craig A. Berry <craig...@nospam.mac.com> wrote:
>> On 5/21/21 12:42 PM, Simon Clubley wrote:
>>> There is a problem when you use net/
>>> within an include statement. The following code compiles: !!!
>>>
>>> ---------------------------------------------------------------------------
>>> $ type nettest.c
>>> #include <stdio.h>
>>> #include <net/does_not_exist.h>
>>>
>>> int main(int argc, char *argv[])
>>> {
>>> printf("Testing net include\n");
>>> return 0;
>>> }
>>> $ cc nettest.c
>>> ---------------------------------------------------------------------------
>>
>> Bug or feature I don't know, but again it seems to have nothing to do
>> with the compiler. Opening a non-existent file on the net: device
>> returns success. What you expect from opening a non-existent file:
>>
>
> I'm not so sure. Based on what has been said so far, I think this
> is a compiler specific problem.
>
> I think John Malmberg is right and that the compiler is wrongly
> looking for a device (NET:) with the name of the net/ include directory
> and using that instead of looking for a [.net] directory.

I think John M is right that something goes wrong, but it's not clear to
me how much, if any, is the compiler's fault and how much is just how
things fall out from all the different special devices.

The compiler would have to have some special handling of prefixes such
as "sys/" and "net/" in order to look things up in
sys$library:decc$rtldef.tlb because a text library is just a key lookup
and there is no nesting. But the fact that the "nl/" prefix shows the
exact same behavior as the "net/" prefix suggests that this isn't the
problem, because /usr/include/nl is not a location that needs to be
emulated in the same way that /usr/include/sys and /usr/include/net do.

>> So the compiler is just converting net/does_not_exist.h to VMS syntax
>> net:does_not_exist.h and getting a successful open but nothing happens
>> when you read from it (except EOF I guess). The filename portion
>> doesn't matter and seems to be ignored. As far as I can tell, the
>> behavior is identical to that of _NLA0:.
>>
>
> That's my understanding as well. What it should be doing instead is
> looking for [.net]does_not_exist.h and then reporting an error when
> it doesn't find the file in that location.

That's the expected behavior for the source code on a Unix system, but
on VMS that's not necessarily correct behavior if "net" is a device name
or a logical name. The logical name case can be suppressed with
DECC$DISABLE_TO_VMS_LOGNAME_TRANSLATION -- you'll probably have to do
that if you have a 'sys" logical name defined.

It does seem possible the compiler is cutting off the prefix and testing
it as a device. That would explain why the following two tests behave
identically:

#include "net/nosuchfile.dat"
#include "nl/nosuchfile.dat"

This one is interesting:

#include "tt/nosuchfile.dat"

It will hang waiting for input from your terminal.

[John E. Malmberg]

On 5/21/2021 12:46 PM, Simon Clubley wrote:
> On 2021-05-21, Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
>> On 2021-05-21, John Reagan <xyzz...@gmail.com> wrote:
>>> I'll do more research but there is nothing of your description that matches what
>>> 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
>>> DECC$POSIX_COMPLIANT_PATHNAMES and watch the compiler not able to find
>>> .TLB files, etc.
>>
>> John is very right about this. There is a problem when you use net/
>> within an include statement. The following code compiles: !!!
>
> That is John Malmberg is right about this. Too many people called John
> around here. :-)

Wrong reproducer. The bug demonstrated in the GNV gnulib_assist self test.

The bug only trips for me with decnet phase IV running which creates a
NET0: device.

type [.vms]test_vms_if_h.c
#ifdef VMS_CRTL
#include <net/if.h>
#else
#include "vms/if.h"
#endif
#pragma assert_m non_zero(__IF_LOADED) "if.h did not get loaded."

Note, I have not tested the fragments posted here.

$ cdef = VMS_CRTL=1"
$ define/user decc$user_include "sys$disk:[.vms]"
$ CC/define=('cdef')'psize''cfloat''cinc'/noobj -
[.vms]test_vms_stdio_h.c


The <net/if.h> is a standard header file used in network programming in C.

You simply can not compile that source if DECNET phase IV is running.
Not sure about Phase V, yanked that out a while back.

I will be posting an update to the gnulib_assist sometime this weekend
after which all the things I have tests for will pass.

Current checked in code has a bug where it is skipping some tests and
the rename wrappers to generate correct rename behavior is not implemented.

Regards,
-John

[Jake Hamby]

Resurrecting this thread: did anyone ever find a resolution to the problem of the C compiler not being able to find headers when they're referenced in quotes with UNIX-style paths? I had trouble with the build script from VSI's Python 3.10.0 port, which I attempted to build on Alpha by changing the strings from I64 to AXP. I finally got a build going only for it to fail with:

CC /FLOAT=IEEE_FLOAT/IEEE=DENORM/NAMES=(AS_IS,SHORTENED)/ACCEPT=NOVAXC_KEYWORDS/REENTRANCY=MULTITHREAD/ARCH=EV56/OPT=(TU
NE=EV67)/ASSUME=NOHEADER_TYPE_DEFAULT/WARNINGS=(WARNINGS=ALL, DISABLE=(EXTRASEMI,MAYLOSEDATA3))/DEBUG/NOOPTIMIZE/LIST=[.
OUT.DEBUG.OBJ.Objects]bytearrayobject/SHOW=ALL/DEFINE=("Py_BUILD_CORE",_USE_STD_STAT, _POSIX_EXIT, __STDC_FORMAT_MACROS,
_LARGEFILE, _SOCKADDR_LEN, __SIGNED_INT_TIME_T, USE_ZLIB_CRC32, _OSF_SOURCE, HAVE_EXPAT_CONFIG_H, XML_POOR_ENTROPY, USE
_PYEXPAT_CAPI, CONFIG_32, ANSI, SOABI="""cpython-310-alpha-openvms""", SHLIB_EXT=""".EXE""", ABIFLAGS="""""", MULTIARCH=
"""cpython-310-alpha-openvms""", PLATFORM="""OpenVMS""", USE_SSL,_DEBUG)/INCLUDE_DIRECTORY=([], [.Include], [.Include.in
ternal], [.Modules.expat], [.Modules._decimal.libmpdec], [.Modules._multiprocessing], [.Modules._io], [.vms], oss$root:[
include], dtr$library, SSL111$ROOT:[INCLUDE]) /OBJECT=[.OUT.DEBUG.OBJ.Objects]bytearrayobject.obc [.Objects]bytearrayobj
ect.c

#include "clinic/bytearrayobject.c.h"
.^
%CC-F-NOINCLFILEF, Cannot find file "clinic/bytearrayobject.c.h" specified in #include directive.
at line number 75 in file USERS:[JHAMBY.Projects.vms-cpython.Objects]bytearrayobject.c;1
%MMS-F-ABORT, For target [.OUT.DEBUG.OBJ.Objects]bytearrayobject.obc, CLI returned abort status: %X10B91264.

No matter what I do, I can't figure out how to get it to locate the "clinic" subdirectory inside "[.Objects]bytearrayobject.c". Now the file ending in ".c.h" has me slightly worried, but I added "/assume=noheader_type_default" and it made no difference. I'm wondering if the problem is that the compiler is replacing the filename, minus the extension, with the name of the header file copied literally, and ending up with something like "[.Objects]clinic/bytearrayobject.c.h" that RMS can't decipher.

I was hoping maybe this was fixed on I64, since otherwise, how is VSI building Python themselves with their own scripts? Has the C compiler been patched to fix this issue and the patch isn't available to noncommercial users like myself? I'd like to find a fix or a workaround because it makes building programs that use header files containing slashes that are searched relative to the source file name (standard default behavior for UNIX compilers for quoted include files) much more difficult.

Regards,
Jake Hamby

[Steven Schweda]

> Resurrecting this thread: did anyone ever find a resolution to the
> problem of the C compiler not being able to find headers when they're

> referenced in quotes with UNIX-style paths? [...]

Looks to me like a different problem.

> [...] I can't figure out how to get it to locate the "clinic"
> subdirectory [...]

That's not the actual problem.

Many "UNIX-style paths" work just fine. Simple paths with multiple
dots also seem to work. _Your_ case fails:

its $ type jh.c;
#include "a.d.g"
#include "sd/b.h"
#include "sd/b.c.h"

its $ cc /noobj jh.c

#include "sd/b.c.h"
.^
%CC-F-NOINCLFILEF, Cannot find file "sd/b.c.h" specified in #include directive.
at line number 3 in file ITS$DKA0:[SMS.itrc.hamby]jh.c;7

The first two directives work. A simple explanation of why the third
one would fail did not leap to my mind.

[Craig A. Berry]

On 5/5/22 6:13 PM, Jake Hamby wrote:

> CC /FLOAT=IEEE_FLOAT/IEEE=DENORM/NAMES=(AS_IS,SHORTENED)/ACCEPT=NOVAXC_KEYWORDS/REENTRANCY=MULTITHREAD/ARCH=EV56/OPT=(TU
> NE=EV67)/ASSUME=NOHEADER_TYPE_DEFAULT/WARNINGS=(WARNINGS=ALL, DISABLE=(EXTRASEMI,MAYLOSEDATA3))/DEBUG/NOOPTIMIZE/LIST=[.
> OUT.DEBUG.OBJ.Objects]bytearrayobject/SHOW=ALL/DEFINE=("Py_BUILD_CORE",_USE_STD_STAT, _POSIX_EXIT, __STDC_FORMAT_MACROS,
> _LARGEFILE, _SOCKADDR_LEN, __SIGNED_INT_TIME_T, USE_ZLIB_CRC32, _OSF_SOURCE, HAVE_EXPAT_CONFIG_H, XML_POOR_ENTROPY, USE
> _PYEXPAT_CAPI, CONFIG_32, ANSI, SOABI="""cpython-310-alpha-openvms""", SHLIB_EXT=""".EXE""", ABIFLAGS="""""", MULTIARCH=
> """cpython-310-alpha-openvms""", PLATFORM="""OpenVMS""", USE_SSL,_DEBUG)/INCLUDE_DIRECTORY=([], [.Include], [.Include.in

If you want those include directories to work with relative paths in
#include directives having relatvie paths and Unix syntax, you'd
probably need to replace:

/INCLUDE=([])

with

/INCLUDE=("./")

> ternal], [.Modules.expat], [.Modules._decimal.libmpdec], [.Modules._multiprocessing], [.Modules._io], [.vms], oss$root:[
> include], dtr$library, SSL111$ROOT:[INCLUDE]) /OBJECT=[.OUT.DEBUG.OBJ.Objects]bytearrayobject.obc [.Objects]bytearrayobj
> ect.c
>
> #include "clinic/bytearrayobject.c.h"
> .^
> %CC-F-NOINCLFILEF, Cannot find file "clinic/bytearrayobject.c.h" specified in #include directive.
> at line number 75 in file USERS:[JHAMBY.Projects.vms-cpython.Objects]bytearrayobject.c;1
> %MMS-F-ABORT, For target [.OUT.DEBUG.OBJ.Objects]bytearrayobject.obc, CLI returned abort status: %X10B91264.
>
> No matter what I do, I can't figure out how to get it to locate the "clinic" subdirectory inside "[.Objects]bytearrayobject.c".

Do you have DECC$EFS_CHARSET defined in the environment? Nothing
involving Unix syntax and two dots in a filename is going to work on VMS
without that.

[abrsvc]

My first guess of the "problem" is perhaps the part of the specification ".c". Is this being interpreted as a file extension for a source file rather than parsed as part of the entire file spec? Try changing the .c to .x and try again. If the new extension works, I would suspect the .c

Dan

[Steven Schweda]

> [...] you'd probably need to replace:

>
> /INCLUDE=([])
>
> with
>
> /INCLUDE=("./")

Did you ever try that?

> [...] Nothing involving Unix syntax and two dots in a filename is

> going to work on VMS without that.

Do you mean as in the demonstration above, where the following worked
properly?:

#include "a.d.g"


> My first guess [...]

Guess again?

its $ type jh2.c
#include "a.d.g"
#include "sd/b.g"
#include "sd/a.d.g"

its $ cc /noobj jh2.c

#include "sd/a.d.g"
.^
%CC-F-NOINCLFILEF, Cannot find file "sd/a.d.g" specified in #include directive.
at line number 3 in file ITS$DKA0:[SMS.itrc.hamby]jh2.c;2

its $ dire [.sd]

Directory ITS$DKA0:[SMS.itrc.hamby.sd]

a^.d.g;1 b^.c.h;1 b.g;1 b.h;1


_Not_ guessing in a case like this is almost as easy as guessing.

[David Jones]

On Thursday, May 5, 2022 at 10:26:26 PM UTC-4, abrsvc wrote:
> My first guess of the "problem" is perhaps the part of the specification ".c". Is this being interpreted as a file extension for a source file rather than parsed as part of the entire file spec? Try changing the .c to .x and try again. If the new extension works, I would suspect the .c
>
> Dan

It's not the ".c", it's the general quirkiness how the CRTL (which the compiler uses)
converts unix-style paths to VMS specifications. Trying defining the logical name
DECC$POSIX_COMPLIANT_PATHS to the value 2, which makes it work on my
system.