| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 2189.1 | Brute-Force Solution... | XDELTA::HOFFMAN | Steve, OpenVMS Engineering | Thu May 15 1997 10:38 | 8 |
|
Sure. Build on V6.1. :-)
(This would be a nice extension to the C compiler, though... This
would have to tie in with the "target RTL" qualifier that has been
discussed, however -- the compiler reads the external symbols out
of the RTL now...)
|
| 2189.2 | Can you redefine the cc verb? | DECC::VOGEL | | Thu May 15 1997 12:16 | 12 |
|
Can you just:
cc:==cc/DEFINE=("__VMS_VER=60100000")/WARNINGS=DISABLE=MACROREDEF
Not a DCL expert, but this works for me.
Ed
|
| 2189.3 | | SPECXN::DERAMO | Dan D'Eramo | Thu May 15 1997 12:22 | 5 |
| You can only have one /DEFINE=(...) on the command line,
so you can't set up CC == "CC/DEFINE=..." before the build
procedure and then use CC/DEFINE=(...) in the build procedure.
Dan
|
| 2189.4 | DEC C setups | WISLA::KIERSTEIN | | Thu May 15 1997 14:50 | 11 |
| All,
I believe I have all the other stuff needed for the environment (like V6.1
DECC$SHR.EXE, DECC$RTLDEF.EXE) defined correctly. The builds run fine on a V6.1
system with SYS$LIBRARY pointing only to the made-up V6.1 environment I had set
up, and the logicals I set up for the images (I patterned this after the VAX
build environment for VMS). As another pointed out, a symbol substitution will
not work for the products that do their own redefining (of which several do).
Just FYI for the problem involved.
Barry
|
| 2189.5 | | DECCXL::OUELLETTE | mudseason into blackfly season | Fri May 16 1997 15:23 | 2 |
| There's been some rumination over this bale of hay.
It's not clear what will come of this.
|
| 2189.6 | | XDELTA::HOFFMAN | Steve, OpenVMS Engineering | Fri May 16 1997 18:22 | 5 |
|
:There's been some rumination over this bale of hay.
:It's not clear what will come of this.
From that analogy, I can guess. :-)
|
| 2189.7 | | TLE::D_SMITH | Duane Smith -- DEC C RTL | Mon May 19 1997 09:46 | 19 |
| In DEC C V5.6 code was added to see if the DECC$SHR.EXE shareable image
contained a new universal symbol. The value at this symbol location
contains the default value for __CRTL_VER. The header files were also
modified to define __CRTL_VER to the same value as __VMS_VER if the new
universal symbol was not found.
This work was done to support the "backport object library" which was
also placed on the DEC C V5.6 kit. When a user follows the
instructions on using the backport library, there is no need to worry
about the definition of __VMS_VER, at least for the C header files.
I am investigating adding this new universal symbol to older DECC$SHR
images as new ECO kits are released for those platforms. If you then
compile on a V7.1 system using a logical name DECC$SHR pointing to a
V6.1 (ecoed) image, the header files will compile using a __CRTL_VER
of 60100000 instead of picking up the default of 70100000 from the
__VMS_VER definition.
Duane
|
| 2189.8 | Workaround for problem | WISLA::KIERSTEIN | | Fri Jun 06 1997 09:23 | 28 |
| Hello,
Duane:
> I am investigating adding this new universal symbol to older DECC$SHR
> images as new ECO kits are released for those platforms. If you then
> compile on a V7.1 system using a logical name DECC$SHR pointing to a
> V6.1 (ecoed) image, the header files will compile using a __CRTL_VER
> of 60100000 instead of picking up the default of 70100000 from the
> __VMS_VER definition.
This would be great!
All:
In case this would be helpful, this is what IPS did as a workaround of
the problem. We created a __DECC_INCLUDE_PROLOGUE.H file with the following
contents:
#undef __VMS_VER
#define __VMS_VER 60100000
Worked like a charm. Since our SYS$LIBRARY definition for the build
processes pointed to the IPS RESD area, and the prologue header file was
put into this area, this did not conflict with the host computer's header
file setup.
Barry
|