[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference turris::c_plus_plus

Title:C++
Notice:Read 1.* and use keywords (e.g. SHOW KEY/FULL KIT_CXX_VAX_VMS)
Moderator:DECCXX::AMARTIN
Created:Fri Nov 06 1987
Last Modified:Thu Jun 05 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:3604
Total number of notes:18242

3468.0. "Unix style of #include files not found with search logical lists on OpenVMS Alpha < 7.1" by BACHUS::DEKEYSER (TP/IM CSC - Belgium DTN 856-8779) Thu Feb 27 1997 13:34

Hi,

My customer has the following problem :

"On my VMS system i have 2 include files :

	dsa1:[project1.rw]file1.h
	dsa1:[project1.rw.sub]file2.h

 On my PC i have the same files on my C partition:

	c:\rw\file1.h
	c:\rw\sub\file2.h

 In Borlandt C++ or MS Visual C++ we set a search path for the include files,
 ie: c:\

 The compiler the finds our files in Unix-syntax :

 #include <rw/file1.h>
 #include <rw/sub/file2.h

 Since we want to compile exactly the same code in VMS and Windows-NT, I made
 a logical on the VMS system :

 $ def rw dsa1:[project1.rw],dsa1:[project1.rw.]

 CXX only uses the first element of the searchlist.

Do you have a solution for my problem ? "

Of course, we do :)

I tested this with DEC C++ V5.5-017 on OpenVMS Alpha V7.1 and everything is
fine.
But my customer is running OpenVMS Alpha V6.2 and it fails as well as with
DEC C++ V5.5-017 on OpenVMS Alpha V6.1-1H2

I did install the latest DECC eco kit (alpacrt09_061) but it didn't change
anything. So i was wondering which rtl fails ?

Thanks and regards,
Rudi
T.RTitleUserPersonal
Name
DateLines
3468.1SPECXN::DERAMODan D'EramoThu Feb 27 1997 15:143
        .-1 reminds me of topics 3138 and 3139 in this conference.
        
        Dan
3468.2What about this ?BACHUS::DEKEYSERTP/IM CSC - Belgium DTN 856-8779Thu Feb 27 1997 16:0046
Well, this becomes stranger, with no logical rw defined at all, look at this :

$ type testje.cxx
#include <rw/file1.h>
#include <rw/sub/file2.h>
void main(void)
{
}
$ cc/version nl:
DEC C++ V5.5-017 on OpenVMS Alpha V7.1
$ cxx/include=tp_im$users:[dekeyser.rw] testje !ok
$ show log tp_im$users /full
"TP_IM$USERS" [exec] = "DBC022$DKA300:[USERS.TP_IM.]" [concealed] (LNM$SYSTEM_
TABLE)
$  cxx/include=DBC022$DKA300:[USERS.TP_IM.dekeyser.rw] testje

#include <rw/file1.h>
.^
%CXX-F-NOINCLFILE, Cannot find file <rw/file1.h> specified in #include directive
.
at line number 1 in file TP_IM$USERS:[DEKEYSER]TESTJE.CXX;1

#include <rw/file1.h>
.^
%CXX-E-NOOBJ, Object file deleted.
at line number 1 in file TP_IM$USERS:[DEKEYSER]TESTJE.CXX;1

$ cxx/version nl:
DEC C++ V5.5-017 on OpenVMS Alpha V6.1-1H2
$ cxx/include=$RDK:[CUSTOMERS.SIDMAR.CXX.rw] testje !ok 
$ show log $rdk/full
 "$RDK" [exec] = "$1$DUA1000:[TP_IM.DEKEYSER.]" [concealed,terminal] (LNM$SYSTEM
_TABLE)
$ cxx/include=$1$DUA1000:[TP_IM.DEKEYSER.CUSTOMERS.SIDMAR.CXX.RW] testje

#include <rw/file1.h>
.^
%CXX-F-NOINCLFILE, Cannot find file <rw/file1.h> specified in #include directive
.
at line number 1 in file $RDK:[CUSTOMERS.SIDMAR.CXX]TESTJE.CXX;1

#include <rw/file1.h>
.^
%CXX-E-NOOBJ, Object file deleted.
at line number 1 in file $RDK:[CUSTOMERS.SIDMAR.CXX]TESTJE.CXX;1

3468.3It may not be simple, but it is operating "as advertised" from the compiler point of view...CXXC::REPETERich Peterson 381-1802 ZKO2-3/N30Fri Feb 28 1997 20:0453
RE .0:

> def rw dsa1:[project1.rw],dsa1:[project1.rw.]

The thought here, I guess, is that by making a search list with
a translation to a directory spec for rw, and to a rooted spec
for directories rooted at rw, that it should work correctly for both

    RW:FILE1.H
      and
    RW:[SUB]FILE2.H

I agree that seems quite logical and nice, but as far as I know it
never has worked that way in RMS.  If you're seeing it work on
OpenVMS V7.1, then I'll guess the change is in RMS services like
SYS$PARSE rather than the DEC C RTL - unless somebody has really
hacked on decc$to_vms to analyze search lists and such.

The problem here is trying to use a VMS search list to simulate the
simple pathname-concatenation processing of NT and UNIX compilers.
You should just use the same mechanism on VMS.  On nt you had:

        c:\rw\file1.h
	c:\rw\sub\file2.h

So you made the include path be the common part preceding the rw in your
#include directives, "c:\".

On VMS, you have:

        dsa1:[project1.rw]file1.h
        dsa1:[project1.rw.sub]file2.h

So you want to do the same thing, and use the include path dsa1:[project1.
The problem is that the VMS syntax rigidly distinguishes directory
names from file names, and you can't just append one or the other
to the same prefix.  Instead of using a VMS logical name containing a
mixture of directory names and root names, just specify the path
using pathname syntax:  /include="/dsa1/project1".


RE .2:

This isn't really a complete reproducer, but I suspect that what's
going on is related either to the current default device/directory,
or something else with RMS defaulting the "device" to include the
directory spec within the concealed rooted logical.  You should
be able to duplicate the behavior using f$parse lexical functions
in DCL.  For a /include qualifier that is not UNIXy and a #include
directive that is UNIXy, the compiler translates the UNIXy name
using decc$to_vms, and then calls $PARSE with the translated name
as the primary filespec and the /include qualifier value as the
default filespec.
3468.4Better to consistently use UNIXy style ...BACHUS::SABLONMon Mar 03 1997 07:5028
3468.5Depends on what you mean by "should"CXXC::REPETERich Peterson 381-1802 ZKO2-3/N30Mon Mar 03 1997 17:2068
>     1. Search the file location indicated by a slash (/). 
>	This is a UNIX-style name that can combine only
>	with UNIX names specified explicitly in the #include
>	directive. It causes a specification like <sys/types.h>
>	to be considered first as /sys/types.h, which will be
>	translated to SYS:TYPES.H.
>
>  So by defining a logical name RW to be the upper directory of inclusion (i.e. 
>  tp_im$users:[dekeyser.rw] in case .2), the compiler should find the included 
>  files. It does in V7.1 but doesn't in V6.2. Probably some changes in VMS or C 
>  RTLs.

If the logical name RW is defined as tp_im$users:[dekeyser.rw], then when
<rw/file1.h> gets translated by step 1 above to rw:file1.h, the file is
found.  But then <rw/sub/file2.h> gets translated to rw:[sub]file2.h,
and with the specified definition for rw this is not a valid filespec;
in order to get this one to work, the definition of rw needs to be a
"rooted" directory spec: tp_im$users:[dekeyser.rw.].  The base note did
not say that the simple definition of rw worked on V7.1, it used a
search list using a combination of simple directory spec and rooted spec:

> $ def rw dsa1:[project1.rw],dsa1:[project1.rw.]

On a V6.2 system using this kind of search list, the $parse service says
that rw:[sub] has an error in the directory name.  I'll guess that V7.1
fixed $parse to be more reasonable.  Even on a V6.2 system, you can notice
a peculiar behavior difference depending on the order of the rooted
and simple directory specs in the translation:

$! Put rooted spec last, top-level ok, subdir absolutely fails
$
$ def rw NT$:[REPETE.CXX3468.RW],NT$:[REPETE.CXX3468.RW.]
$ dir rw:file1.h

Directory NT$:[REPETE.CXX3468.RW]

FILE1.H;1

Total of 1 file.
$ dir rw:[sub]file2.h
%DIRECT-E-OPENIN, error opening RW:[SUB]FILE2.H as input
-RMS-F-DIR, error in directory name
$
$! Put rooted spec first, top-level ok, subdir complains but file still found!
$
$ def rw NT$:[REPETE.CXX3468.RW.],NT$:[REPETE.CXX3468.RW]
$ dir rw:file1.h

Directory NT$:[REPETE.CXX3468.RW]

FILE1.H;1

Total of 1 file.
$ dir rw:[sub]file2.h

Directory NT$:[REPETE.CXX3468.RW.][SUB]

%DIRECT-E-OPENIN, error opening RW:[SUB]FILE2.H as input
-RMS-F-DIR, error in directory name
FILE2.H;1

Total of 1 file.
$

But as suggested both in .3 and .4, since they're trying to duplicate an
NT environment where pathnames concatenate essentially the same as on UNIX,
they're better of using the concatenable UNIXy style of name in the
/include qualifier.