| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 3436.1 | request for more info | HYDRA::DORHAMER | | Thu Apr 03 1997 12:40 | 19 |
| #1 3-APR-1997 11:38:32.47
NEWMAIL
From: HYDRA::AXPDEVELOPER "[email protected]"
To: SMTP%"[email protected]"
CC: AXPDEVELOPER
Subj: RE: CPP PROBLEM WITH SHAREABLE IMAGES
TO: Steven Popkes
Steve,
I'm investigating your C++ shared library question and it would be helpful
to know two things:
1) Are you running on a VAX or an Alpha system?
2) What version of the C++ compiler is installed?
Thanks,
Karen
|
| 3436.2 | | HYDRA::DORHAMER | | Thu Apr 03 1997 13:46 | 11 |
| #15 3-APR-1997 12:34:35.32
MAIL
From: SMTP%"[email protected]"
To: "[email protected]" <[email protected]>
CC:
Subj: Re: CPP PROBLEM WITH SHAREABLE IMAGES
Thanks for returning the letter. We are running c++ version 4.010
(according to the listing) and we are running an Alpha, with open VMS,
version 6.2..
|
| 3436.3 | recommend compiler upgrade | HYDRA::DORHAMER | | Thu Apr 03 1997 13:53 | 20 |
| #2 3-APR-1997 12:51:55.21
NEWMAI
L
From: HYDRA::AXPDEVELOPER "[email protected]"
To: SMTP%"[email protected]"
CC: AXPDEVELOPER
Subj: Re: CPP PROBLEM WITH SHAREABLE IMAGES
TO: Steven Popkes
Steve,
Thanks for sending the compiler version. v4.0 is a fairly old version
of the compiler. The current release is v5.5. You may want to consider
upgrading. This doesn't impact your shared library question, but there
are many enhancements and performance optimizations in the v5.5 compiler
that you may benefit from.
Karen Dorhamer
Alpha Developer Support
|
| 3436.4 | clarification | HYDRA::DORHAMER | | Fri Apr 04 1997 10:11 | 20 |
| From: SMTP%"[email protected]" 3-APR-1997 17:19:23.36
To: karen dorhamer <[email protected]>
CC:
Subj: CPP PROBLEM
Karen,
I worked with the cpp problem and made it a little more accessible. I still
have the problem with how to expose c++ components to the world. I need to
know 1) how to expose the real names generated by the cxx compiler or 2)
how to expose the mangled names. Obviously, the former is desireable. I'm
sure there's a way but I don't have it. We're working with VMS 6.,2 and
can go up to 6.4, since our client, the DOD, are up to that. We can't go to
VMS 7.* until they do. The c++ versions you mentioned: are they
compatible with VMS 6.*? And is the problem I'm having one of an old
version of cxxlink?
Thanks,
Steve Popkes
|
| 3436.5 | looking for documentation | HYDRA::DORHAMER | | Fri Apr 04 1997 10:20 | 23 |
| #1 4-APR-1997 09:19:35.81
NEWMAIL
From: HYDRA::AXPDEVELOPER "[email protected]"
To: SMTP%"[email protected]"
CC: AXPDEVELOPER
Subj: RE: CPP PROBLEM
Steve,
The current version of C++ (v5.5) is supported on OpenVMS v6.1 and up. You
can install this on your 6.2 system. I don't know if the problem is related
to having such an old version of the compiler, but it would be beneficial
to use the current version to obtain all of the bug fixes, performance
enhancements and new features available in this version of the compiler.
I am checking with C++ engineering about how to correctly create shareable
images. The current C++ documentation does not cover this, but we are
trying to locate an old (1993) version of the "Using DEC C++ on OpenVMS
Systems" manual, which contained a chapter on creating shareable images.
If you happen to have an older copy of the documentation, please check to
see if it contains this chapter.
Karen
|
| 3436.6 | perl script to build symbol vector | HYDRA::DORHAMER | | Fri Apr 04 1997 10:26 | 96 |
| #1 4-APR-1997 09:24:03.97
NEWMAIL
From: HYDRA::AXPDEVELOPER "[email protected]"
To: SMTP%"[email protected]"
CC: AXPDEVELOPER
Subj: perl script to build symbol vector for C++ shared library
Steve,
Attached is a perl script that someone wrote to build the symbol vector
for C++ shared images. Please let me know if this helps you out.
Karen
-< C++ >-
================================================================================
-< Building the Symbol Vector for alphas >-
--------------------------------------------------------------------------------
If you're not that interested in release compatibility (order and index
of entries in the symbol vector), here's the main part of a PERL (sorry,
I'm new to PERL so don't wince too much...) script I wrote that digs
through an object file and spits out the global symbols in a symbol_vector
directive. I convert/append the results of this to a .opt file to make all
the global symbols in the object files part of the universal symbols in the
shared library. It makes going from .objs to shared libraries pretty easy,
but at the expense of having to relink everything that depends on it every
time I build a new version of the library.
#!perl
# Strip off the .olb or .obj at the end
$extension = substr ($ARGV[0], -4);
$libname = substr ($ARGV[0], 0, -4);
# If it's an object library, extract all the modules into a single
# .obj with the same base name.
if (($extension == ".olb") || ($extension == ".OLB")) {
system ('library/extract=* ' . $libname . '.olb');
}
# Have analyze dump the symbol table
system ('analyze/object/gsd ' . $libname . '.obj' .
'/output=' . $libname . '.analyze');
open (ANALFILE, $libname . '.analyze');
open (OPTFILE, '>' . $libname . '.symvec');
$accept = 0;
$definition = 0;
$procedure = 0;
$count = 10000;
while (<ANALFILE>) {
if (/Global Symbol Specification/) {
$accept = 1;
}
elsif (/EGSY\$V_DEF/) {
$definition = substr($_, 25);
}
elsif (/EGSY\$V_NORM/) {
$procedure = substr($_, 25);
}
elsif (/symbol:/) {
if (($accept == 1) && ($definition == 1)) {
if ($count > 1000) {
print OPTFILE "symbol_vector=(-\n";
$count = 16;
}
else {
print OPTFILE ",-\n";
$count += 2;
}
$symbol = substr ($_, 11, -2);
print OPTFILE $symbol;
$count += length ($symbol);
if ($procedure == 1) {
print OPTFILE "=PROC";
}
else {
print OPTFILE "=DATA";
}
$count += 5;
$accept = 0;
if ($count > 1000) {
print OPTFILE ")\n";
}
}
}
}
if ($count <= 1000) {
print OPTFILE ")\n";
}
close (OPTFILE);
close (ANALFILE);
|
| 3436.7 | response | HYDRA::DORHAMER | | Fri Apr 04 1997 12:14 | 10 |
| #3 4-APR-1997 11:13:05.53
NEWMAIL
From: SMTP%"[email protected]"
To: "[email protected]" <[email protected]>
CC:
Subj: Re: CPP PROBLEM
Thanks. Getting that documentation would be GREAT!
Stevep
|
| 3436.8 | received script | HYDRA::DORHAMER | | Fri Apr 04 1997 12:35 | 11 |
| #4 4-APR-1997 11:23:13.80
NEWMAIL
From: SMTP%"[email protected]"
To: "[email protected]" <[email protected]>
CC:
Subj: Re: perl script to build symbol vector for C++ shared library
Received the perl script. I don't know perl at all, or if we have it, but
I'll look through it. Thanks.
Stevep
|
| 3436.9 | problem with /NOINFORMATIONALS switch | HYDRA::DORHAMER | | Mon Apr 07 1997 10:59 | 281 |
| #32 4-APR-1997 17:19:18.17
1997-04
From: SMTP%"[email protected]"
To: KAREN DORHAMER <[email protected]>
Subj: UPDATE FROM US AND POSSIBLE CXXLINK BUG
Karen,
I wasn't sure where to send this. I believe I've found a bug in the cxxlink
program that is shipped with c++. We're now using version 5.5 under 6.2
on an alpha.
Anyway, when the /NOINFORMATIONALS option is used, the linker no longer
finds and compiles template files. Nor does it shut off informational
messages.
Enclosed are two runs of exactly the same link DCL file, using exactly the
same object files. The only difference between the two is the addition
of /NOINFORMATIONALS in the failed run. The reason for using
/NOINFORMATIONALS was to get rid of the output from the linker as to the
contents of the .OPT files.
BTW: the security key fix worked like a charm. Also: I checked whether we
could use PERL, but we don't have it. Besides which, it doesn't really
solve our problem.
As a workaround, I tried to put the straight C code into an executable
library and have it call out to the calling program by way of a c++
object pointer. Unfortunately, the linker complained it didn't have the
proper object files. Consequently, to make that work I'd have to link
in the object files to the shareable image and into the calling
program.
Is there a way to make the linker recognize that when it actually runs
the code will be there? So that the pointer can be initialize to be a
target outside of the shareable image:
calling program shareable image
object z of class x function y
w/ pointer to class x
The idea would be the calling program would come up and during
initialization, it would set the value of function y's pointer to
object z. From there on out, all things would proceed normally. The
linker complains unless there is object code of class x in the shareable
image. This would be okay, but the name mangling problem is defeating me
from linking the calling program to the object code in the shareable
image. Hence, to make this work, I have to have the object code in both
the calling program *and* the shareable image.
I stuck with using a shareable image because DSM only talks across
a package interface that uses such a thing. And we have more than one
project here in the shop that uses DSM. Currently, the only way we have
for both projects to talk with DSM is to make two shareable images, each
with much of the same code: one for one project and the second for the
other.
Hope this gives more light on the subject.
Stevep
========================================================================
============================= correct run
==============================
========================================================================
@build_ds_link
$SET VERIFY
$ cxxlink /SHARE/map/exec=dataservices.exe -
esi$dsmecall_dataservices.obj,-
dataobjects.obj,-
seqlist.obj,-
namepairs.obj,-
vmsdataservices.obj,-
esigenfunctions.obj,-
esivmsobject.obj,-
sys$library:dsm$ecall.opt/option
LINK /SHARE/MAP/EXEC=DATASERVICES.EXE
ESI$DSMECALL_DATASERVICES.OBJ,ESI$DKA200:
[DEODEV.DSM_SERVER]CXX_REPOSITORY.OPT/OPT,DATAOBJECTS.OBJ,SEQLIST.OBJ,NAMEPAIRS.
OBJ,VMSDATASERVICES.OBJ,ESIGENFUNCTIONS.OBJ,ESIVMSOBJECT.OBJ,SYS$LIBRARY:DSM$ECA
LL.OPT/OPTION -
,SYS$LIBRARY:LIBCXXSTD.OLB/LIB
SYS$DISK:[.CXX_REPOSITORY]CXX$TMpHndlr19tgSDSQVRAN182kad4.obj
SYS$DISK:[.CXX_REPOSITORY]CXX$TMpHndlr21tgSDNMDVRA0vr9heo.obj
SYS$DISK:[.CXX_REPOSITORY]TMapHandler___15tagESIDO_BROKER.obj
!
! D S M
! D S M $ E C A L L . O P T
! ALPHA DSM External Call Linker Option File
!
!++
!Copyright (c) Digital Equipment Corporation, 1992
!All Rights Reserved. Unpublished rights reserved
!under the copyright laws of the United States.
!
!The software contained on this media is proprietary
!to and embodies the confidential technology of
!Digital Equipment Corporation. Possession, use,
!duplication or dissemination of the software and
!media is authorized only pursuant to a valid written
!license from Digital Equipment Corporation.
!
!RESTRICTED RIGHTS LEGEND Use, duplication, or
!disclosure by the U.S. Government is subject to
!restrictions as set forth in Subparagraph (c)(1)(ii)
!of DFARS 252.227-7013, or in FAR 52.227-19, as
!applicable.
!--
!++
!
!Facility: DSM
!
!Description:
!
!DSM$ECALL.OPT - linker option file to declare universal
!symbol DSM$ZCALL_TABLE as the External Call table base.
!
!--
SYMBOL_VECTOR=(DSM$ZCALL_TABLE = DATA )
$
========================================================================
============================= failed run
===============================
========================================================================
$
$ @BUILD_DS_LINK
$SET VERIFY
$ cxxlink /NOINFORMATIONALS/SHARE/map/exec=dataservices.exe -
esi$dsmecall_dataservices.obj,-
dataobjects.obj,-
seqlist.obj,-
namepairs.obj,-
vmsdataservices.obj,-
esigenfunctions.obj,-
esivmsobject.obj,-
sys$library:dsm$ecall.opt/option
LINK /NOINFORMATIONALS/SHARE/MAP/EXEC=DATASERVICES.EXE
ESI$DSMECALL_DATASERVICE
S.OBJ,DATAOBJECTS.OBJ,SEQLIST.OBJ,NAMEPAIRS.OBJ,VMSDATASERVICES.OBJ,ESIGENFUNCTI
ONS.OBJ,ESIVMSOBJECT.OBJ,SYS$LIBRARY:DSM$ECALL.OPT/OPTION
,SYS$LIBRARY:LIBCXXSTD
.OLB/LIB
!
! D S M
! D S M $ E C A L L . O P T
! ALPHA DSM External Call Linker Option File
!
!++
!Copyright (c) Digital Equipment Corporation, 1992
!All Rights Reserved. Unpublished rights reserved
!under the copyright laws of the United States.
!
!The software contained on this media is proprietary
!to and embodies the confidential technology of
!Digital Equipment Corporation. Possession, use,
!duplication or dissemination of the software and
!media is authorized only pursuant to a valid written
!license from Digital Equipment Corporation.
!
!RESTRICTED RIGHTS LEGEND Use, duplication, or
!disclosure by the U.S. Government is subject to
!restrictions as set forth in Subparagraph (c)(1)(ii)
!of DFARS 252.227-7013, or in FAR 52.227-19, as
!applicable.
!--
!++
!
!Facility: DSM
!
!Description:
!
!DSM$ECALL.OPT - linker option file to declare universal
!symbol DSM$ZCALL_TABLE as the External Call table base.
!
!--
SYMBOL_VECTOR=(DSM$ZCALL_TABLE = DATA )
%LINK-W-NUDFSYMS, 17 undefined symbols:
%LINK-W-USEUNDEF, undefined symbol TMapHandler<tagESIDO_BROKER
>::TMapHandler(vo
id) referenced
in psect $LINK$ offset %X00000020
in module DATAOBJECTS file
ESI$DKA200:[DEODEV.DSM_SERVER]DATAOBJECTS.OBJ
;8
%LINK-W-USEUNDEF, undefined symbol void TMapHandler<tagESIDO_BROKER
>::DeleteCel
l(int) referenced
in psect $LINK$ offset %X000000D0
in module DATAOBJECTS file
ESI$DKA200:[DEODEV.DSM_SERVER]DATAOBJECTS.OBJ
;8
%LINK-W-USEUNDEF, undefined symbol int TMapHandler<tagESIDO_BROKER
>::SecureId(i
nt) referenced
in psect $LINK$ offset %X00000110
in module DATAOBJECTS file
ESI$DKA200:[DEODEV.DSM_SERVER]DATAOBJECTS.OBJ
;8
%LINK-W-USEUNDEF, undefined symbol int TMapHandler<tagESIDO_BROKER
>::SecureToke
n(tagESIDO_BROKER *) referenced
in psect $LINK$ offset %X00000170
in module DATAOBJECTS file
ESI$DKA200:[DEODEV.DSM_SERVER]DATAOBJECTS.OBJ
;8
%LINK-W-USEUNDEF, undefined symbol int TMapHandler<tagESIDO_BROKER
>::AllocateCe
ll(void) referenced
in psect $LINK$ offset %X00000210
in module DATAOBJECTS file
ESI$DKA200:[DEODEV.DSM_SERVER]DATAOBJECTS.OBJ
;8
%LINK-W-USEUNDEF, undefined symbol void TMapHandler<tagESIDO_BROKER
>::DeleteAll
Cells(void) referenced
in psect $LINK$ offset %X00000240
in module DATAOBJECTS file
ESI$DKA200:[DEODEV.DSM_SERVER]DATAOBJECTS.OBJ
;8
%LINK-W-USEUNDEF, undefined symbol TMapHandler<tagESIDO_BROKER
>::~TMapHandler(v
oid) referenced
in psect $LINK$ offset %X00000280
in module DATAOBJECTS file
ESI$DKA200:[DEODEV.DSM_SERVER]DATAOBJECTS.OBJ
;8
%LINK-W-USEUNDEF, undefined symbol TMapHandler<tagESIDO_SEQVARIANT
>::TMapHandle
r(void) referenced
in psect $LINK$ offset %X00000030
in module SEQLIST file ESI$DKA200:[DEODEV.DSM_SERVER]SEQLIST.OBJ;2
%LINK-W-USEUNDEF, undefined symbol void TMapHandler<tagESIDO_SEQVARIANT
>::Delet
eCell(int) referenced
in psect $LINK$ offset %X00000060
in module SEQLIST file ESI$DKA200:[DEODEV.DSM_SERVER]SEQLIST.OBJ;2
%LINK-W-USEUNDEF, undefined symbol int TMapHandler<tagESIDO_SEQVARIANT
>::GetNex
tCell(int) referenced
in psect $LINK$ offset %X00000110
in module SEQLIST file ESI$DKA200:[DEODEV.DSM_SERVER]SEQLIST.OBJ;2
%LINK-W-USEUNDEF, undefined symbol int TMapHandler<tagESIDO_SEQVARIANT
>::Alloca
teCell(void) referenced
in psect $LINK$ offset %X00000180
in module SEQLIST file ESI$DKA200:[DEODEV.DSM_SERVER]SEQLIST.OBJ;2
%LINK-W-USEUNDEF, undefined symbol TMapHandler<tagESIDO_SEQVARIANT
>::~TMapHandl
er(void) referenced
in psect $LINK$ offset %X000001C0
in module SEQLIST file ESI$DKA200:[DEODEV.DSM_SERVER]SEQLIST.OBJ;2
%LINK-W-USEUNDEF, undefined symbol TMapHandler<tagESIDO_NAMEDVARIANT
>::TMapHand
ler(void) referenced
in psect $LINK$ offset %X00000030
in module NAMEPAIRS file ESI$DKA200:[DEODEV.DSM_SERVER]NAMEPAIRS.OBJ;1
%LINK-W-USEUNDEF, undefined symbol void
TMapHandler<tagESIDO_NAMEDVARIANT >::Del
eteCell(int) referenced
in psect $LINK$ offset %X000000B0
in module NAMEPAIRS file ESI$DKA200:[DEODEV.DSM_SERVER]NAMEPAIRS.OBJ;1
%LINK-W-USEUNDEF, undefined symbol int
TMapHandler<tagESIDO_NAMEDVARIANT >::GetN
extCell(int) referenced
in psect $LINK$ offset %X00000190
in module NAMEPAIRS file ESI$DKA200:[DEODEV.DSM_SERVER]NAMEPAIRS.OBJ;1
%LINK-W-USEUNDEF, undefined symbol int
TMapHandler<tagESIDO_NAMEDVARIANT >::Allo
cateCell(void) referenced
in psect $LINK$ offset %X00000200
in module NAMEPAIRS file ESI$DKA200:[DEODEV.DSM_SERVER]NAMEPAIRS.OBJ;1
%LINK-W-USEUNDEF, undefined symbol TMapHandler<tagESIDO_NAMEDVARIANT
>::~TMapHan
dler(void) referenced
in psect $LINK$ offset %X000002A0
in module NAMEPAIRS file ESI$DKA200:[DEODEV.DSM_SERVER]NAMEPAIRS.OBJ;1
$
|
| 3436.10 | response | HYDRA::DORHAMER | | Mon Apr 07 1997 11:01 | 20 |
| #38 7-APR-1997 09:50:41.86
1997-04
From: HYDRA::AXPDEVELOPER "[email protected]"
To: SMTP%"[email protected]"
CC: AXPDEVELOPER
Subj: RE: UPDATE FROM US AND POSSIBLE CXXLINK BUG
TO: Steve Popkes
Steve,
The C++ compiler group has promised to send me information on how to create
a C++ shareable image. I'll pass that on to you as soon as I receive it.
I will also check with the compiler group about the /NOINFORMATIONALS
problem.
I'm glad to hear that the DCE security key solution has solved your problem.
Karen
|
| 3436.11 | known bug | HYDRA::DORHAMER | | Thu Apr 10 1997 12:48 | 27 |
| #1 10-APR-1997 11:47:33.92
NEWMAIL
From: HYDRA::AXPDEVELOPER "[email protected]"
To: SMTP%"[email protected]"
CC: AXPDEVELOPER
Subj: /NOINFORMATAIONALS switch
TO: Steve Popkes
Steve,
The DEC C++ group stated that the problem with /NOINFORMATIONALS is a
known bug which will be fixed in the v5.6 compiler. I'm checking on the
schedule for v5.6.
Karen
-< C++ >-
================================================================================
Note 3532.1 cxxlink /NOINFORMATIONALS question
1 of 1
--------------------------------------------------------------------------------
Yes it a bug. The prelink quals on OpenVMS Alpha should include /inform
to override the user's use of /noinform. The qualifier does not exist for
the OpenVMS VAX linker.
The code has been fixed and will be part of V5.6 release.
|
| 3436.12 | v5.6 ships in August | HYDRA::DORHAMER | | Mon Apr 14 1997 11:09 | 6 |
|
Note 3532.3 cxxlink /NOINFORMATIONALS question 3 of 3
DECCXX::MITCHELL 1 line 10-APR-1997 16:38
-< V5.6 ship date on OpenVMS Alpha >-
FCS date is in August, 1997.
|
| 3436.13 | documentation on creating C++ shareable images | HYDRA::DORHAMER | | Wed Apr 16 1997 11:31 | 301 |
| #1 16-APR-1997 10:27:37.03
NEWMAIL
From: HYDRA::AXPDEVELOPER "[email protected]"
To: US6RMC::"[email protected]"
CC: AXPDEVELOPER
Subj: C++ shareable image documentation
TO: Steve Popkes
Steve,
The attached HTML file describes how to create C++ shareable images for
OpenVMS.
Karen
<HTML>
<HEAD>
<TITLE>Creating an OpenVMS Shareable Image from DEC C++ Source Code</TITLE>
</HEAD>
<hr size=10 width=30%>
<h1>Introduction</h1>
Before attempting to create a shareable image on OpenVMS, the
OpenVMS Linker Utility manual's section describing shareable images
should be reviewed.
<p>
The steps described are not intended cover all of the details of creating
shareable images, they are instead intended to address the unique
problems related to performing this task for C++ code.
<hr><h2>Determining which names to export</h2>
The set of header file(s) containing class definitions for your
product will determine what routines and data need to be be exported by
your shareable image. Any member function or data declared as public
in a class will need to be exported with the only exception
being inline functions whose code exists within the header file itself.
<p>
DEC C++ encodes type information in function and data names, it is
these encoded names that need to be exported, not the function name
that appears in the code.
<p>
For example:
<code_example><pre>
class test {
public:
void show_it();
void show_it(int);
};
</pre></code_example>
<p>
The function <code_example>show_it</code_example> would end up generating the
name <code_example>SHOW_IT__4TESTXV</code_example> while the function
<code_example>show_it</code_example> would end up generating the name
<code_example>SHOW_IT__4TESTXI</code_example>.
<p>
Generating a list of symbols that need to be exported is the single most
complicated part of creating a shareable image that provides support for
a C++ code base. The procedure involves several steps requiring human
intervention and a knowledge of the interfaces that are to be made available.
<p>
Here are the steps for OpenVMS Alpha:
<ol>
<li>Place all object modules that will be part of the shareable image
into a object library.
<br><code_example>
$ LIBRARY/CREATE sw.olb sw.obj,sw_vec_alpha.obj
</code_example><br>
<li>Execute the following command:
<br><code_example>
$ LIBRARY/LIST=sw_shr_alpha.opt/NAMES sw.olb
</code_example><br>
<li>Edit SW_SHR_ALPHA.OPT, remove any extra lines that
are not global names and change the remaining
lines so they look like this:
<p>
<code_example>
SYMBOL_VECTOR=(MYSHARE_G_TEST = PROCEDURE)<br>
SYMBOL_VECTOR=(MYSHARE__9FOOBARRTHXV = PROCEDURE)<br>
</code_example><br>
<p>
You should only include names you know you wish to export.
If you used the <a hrefe=#extern_prefix>__extern_prefix</a>
directive correctly, each name you need to export will contain that
prefix.
<p>
If you are exporting a pointer to a class instance, and you are
using the macros provided in the example code, the LIB/LIST/NAMES
listing will contain both the global pointer (from the macro source)
and the "_DATA" version (from the C++ source). Only the
global pointer from the macro source should be included in the
symbol vector.
<li>Test link using that options file:
<br><code_example>
$ LINK/SHARE/EXE=SW_SHR.EXE sw.obj,sw_vec_alpha.obj,sw_shr_alpha.opt/opt
</code_example><br>
<li>Expect to see several warnings in the form:
<pre>
%LINK-W-SYMVABNORMAL, Symbol SW_G_SW
defined in module SW as DATA
was declared in options as PROCEDURE
</pre>
<p>
Re-edit the linker options file and change each of these lines to be:
<br><code_example>
SYMBOL_VECTOR=(SW_G_SW = DATA)<br>
</code_example><br>
<p>
and try the link command again.
<li>Continue the process until the linker reports no more errors.
</ol>
<p>
Here are the steps for OpenVMS VAX:
<ol>
<li>Place all object modules that will be part of the shareable image
into a object library.
<br><code_example>
$ LIBRARY/CREATE sw.olb sw.obj,sw_vec_alpha.obj
</code_example><br>
<li>Execute the following command:
<br><code_example>
$ LIBRARY/LIST=sw_vec_vax.mar/NAMES sw.olb
</code_example><br>
<li>Edit the SW_VEC_VAX.MAR file, remove any extra
lines that are not global names and change
the remaining lines as follows:
<br>External Data:
<p>
<code_example>
$GSYM SW_G_SW SW_G_SW_DATA<br>
</code_example>
<p>
This exports the SW_G_SW name and points it at
SW_G_SW_DATA (which is not exported).
<p>
External Routines:
<code_example><br>
$CALL SW_USER__9STOPWATCHXV<br>
</code_example><br>
<p>
You should only include names you know you wish to export.
If you used the <a hrefe=#extern_prefix>__extern_prefix</a>
directive correctly, each name you need to export will contain that
prefix.
<p>
If you are exporting a pointer to a class instance, and you are
using the macros provided in the example code, the LIB/LIST/NAMES
listing will contain both the global pointer (from the macro source)
and the "_DATA" version (from the C++ source). Only the
global pointer from the macro source should be listed here.
<p>
The macros $GSYM and $CALL need to be defined also (see the
example code).
<li>Test link using that options file:
<br><code_example>
$ LINK/SHARE/EXE=SW_SHR.EXE sw.obj,sw_vec_vax.obj,sw_shr_vax.opt/opt
</code_example><br>
</ol>
<p>
If you have questions about what the mangled names actually translate
into, use the CXXDEMANGLE utility to view their unmangled translation.
<p>
Once done, you should be able to link and run your public_entry program
against this shareable image:
<br><code_example>
$ DEFINE MY_SHARE SYS$DISK:[]MY_SHARE.EXE<BR>
$ LINK public_entry,sys$input:/opt<BR>
MY_SHARE/SHARE<BR>
<CTRL/Z><BR>
$ RUN public_entry
</code_example><br>
<p>
The results should be the same as the test being linked against the
object modules used to create the shareable image.
<p>
If the test output differs or if the link fails then the above steps
need to be verified and re-executed.
<hr><hr size=10 width=50%><hr><h1><center>Additional Topics</center></h1>
<p>
The sections below describe some common topics that relate to OpenVMS
Shareable images and DEC C++. They are provided to help DEC C++ users on
OpenVMS better understand the extra steps are required in creation of
a shareable image that is both coded in C++ and provides support for
C++ class objects.
<hr><h2>Testing </h2>
A test which accesses all entry points should be written. The test
needs to be verified by hand to make sure it accesses each class member
function or data.
<p>
The test should first be linked against the same set of objects that were
used to create the shareable image. It should then be relinked using the
shareable image. The two test images should have the same results.
<p>
This test can also be used to verify upward compatibility of your
shareable image.
<hr><h2>Adding New Entry Points</h2>
<p>
If new classes or new member functions are added, the
$ LIB/LIST/NAMES step described earlier can be used to determine the
new encoded names that need to be exported. Existing names must remain
if upward compatibility of the shareable image is to be maintained.
See the OpenVMS Linker Utility manual for more details on extending
a shareable image's global entry point list.
<hr><h2><a name=extern_prefix>Generating Unique Names </a></h2>
A provider of a shareable image should protect themselves against global
name conflicts with other shareable images and software packages.
<p>
The recommended method of doing this using DEC C++ is by using the
compiler #pragma __extern_prefix directive:
<p><code_example>
#pragma __extern_prefix "sw_"
<code_example>
<p>
This results in all global data and global routines being prefixed
with "sw_" as part of their encoded name.
<p>
The example show how __extern_prefix can be safely used within public
header files.
<hr><h2>Transfer Vectors and Symbol Vectors</h2>
<p>
A Transfer Vector is the term used to describe the area of a shareable
image on OpenVMS VAX that contains its public interface (or Entry Points).
<p>
The only way to create this area is by using VAX MACRO.
<p>
A Symbol Vector is the term used to describe the entry points for an
OpenVMS Alpha shareable image. The symbol vector is created via
the SYMBOL_VECTOR directive in a linker options file.
<hr><h2>Global Data</h2>
<p>
In order for a shareable image to export a global instance of a class (for
example, "cout" from CXXL$011_SHR) it must export a pointer to that
instance. The OpenVMS Linker Utility manual describes this type of
export as a "data cell".
<p>
Exporting a pointer allows the author of the shareable image the option of
modifying the class definition in a future release. Care must be taken to
not effect the memory layout of the class.
<p>
The example shows how the exporting of the pointer can be made
somewhat invisible to the shareable image user.
<hr><h2>Initilization of Global Data</h2>
<p>
The DEC C++ compiler will generate code in the LIB$INITIALIZE image
program section (psect) which will call every global objects's
constructor routine before the program executes its first statement.
<p>
This is true for a shareable image's global data also. The OpenVMS
image activator will call each LIB$INITIALIZE contribution for each
shareable image that is linked into a program which means that
before a program executed any code, any global classes in the
any shareable images that it references have had their constructors
called.
<p>
If you plan on providing an option of linking with an object library
form of your shareable image, please refer to the
<u>Using DEC C++ for OpenVMS Systems</u> manual and its section
on Linking Against the DEC C++ Class Library Object Library as an
example of how users of the object library should link their
application.
<hr><h2>Virtual Functions</h2>
<p>
The virtual functions can not be added to public classes without breaking
compatibility. The method used to implement virtual function tables
in the C++ object model is what imposes this limitation.
See the Using DEC C++ for OpenVMS manual for more details on the
C++ object model.
<hr>
<hr><h2>Using UNIVERSAL= </h2>
<p>
On OpenVMS VAX, you have the option of exporting global data and routines
by using the UNIVERSIAL option in a linker options file. Using this
option requires any image linked against the shareable image to relink
every time the shareable image is rebuilt. It is because of this that the
use of this feature is not recommended.
<hr>
<A HREF="mailto:[email protected]">[email protected]</A>
</BODY>
</HTML>
|
| 3436.14 | instructions for unpacking uuencoded saveset | HYDRA::DORHAMER | | Wed Apr 23 1997 14:57 | 52 |
| #5 23-APR-1997 13:51:56.91
NEWMAIL
From: HYDRA::AXPDEVELOPER "[email protected]"
To: US6RMC::"[email protected]"
CC: AXPDEVELOPER
Subj: Instructions for unpacking saveset with shareable image examples
TO: Steve Popkes
Steve,
Attached are instructions for unpacking a uuencoded saveset that will
contain examples regarding creating C++ shareable images. The next mail
message will contain the actual saveset.
How are things going? Were the instructions that I forwarded to you last
week helpful? Please let me know if you need any further help.
Karen
Subj: First of two mail messages for 'shareable image' customer
Here are the steps to unpack the SW_SHR.SAV BACKUP saveset:
1) Extract the mail message to a file called sw_shr.uue
2) Remove anything before the line:
begin 775 sw_shr.sav-dcx_axpexe
and after the line:
end
3) UUDecode the file:
$ MCR UCX$UUDECODE sw_shr.uue
4) Decompress the file:
$ run SW_SHR.SAV-DCX_AXPEXE
You will be prompted for the directory into which you want to place
the uncompressed BACKUP saveset.
5) Unpack the saveset:
$ BACKUP sw_shr.sav/sav *
The saveset contains all the source files and HTML documentation on the
examples.
|
| 3436.15 | sent saveet | HYDRA::DORHAMER | | Wed Apr 23 1997 15:00 | 4 |
| The actual saveset can be found in the e-mail that I sent to Steve
on April 23rd, filed in the 1997-04 mail folder.
Karen
|
| 3436.16 | I resent the encoded file | HYDRA::DORHAMER | | Thu Apr 24 1997 10:49 | 14 |
| From: US6RMC::"[email protected]" "Esi Technology Corp"
23-APR-1997 17:57:14.86
To: "\"[email protected]\"" <hydra::axpdeveloper>
CC:
Subj: Re: Instructions for unpacking saveset with shareable image
examples
I got the html file you sent me. I didn't receive the uuencode stuff
yet. I'm still pondering the methodology of creating the shared image.
It's a pity virtual functions aren't allowed.
stevep
|
| 3436.17 | C++ engineering looking for feedback | HYDRA::DORHAMER | | Mon Apr 28 1997 14:51 | 21 |
| #4 28-APR-1997 13:41:50.41
NEWMAIL
From: HYDRA::AXPDEVELOPER "[email protected]"
To: SMTP%"[email protected]"
CC: AXPDEVELOPER
Subj: Re: SHARED EXECUTABLE PROBLEM
TO: Steve Popkes
Steve,
The C++ engineer is interested in your feedback on the material that
he provided (instructions and examples) regarding creating a C++ shareable
image. He is considering including this info in the next version of the
documentation. Any feedback that you have would be helpful. Also, we
certainly want to help you out if you have any questions or need
clarification of this material.
Thanks,
Karen
|
| 3436.18 | another example | HYDRA::DORHAMER | | Tue Apr 29 1997 14:04 | 151 |
| From: HYDRA::AXPDEVELOPER "[email protected]"
To: SMTP%"[email protected]"
CC: AXPDEVELOPER
Subj: another example for creating shared images
Steve,
Another engineer from VMS engineering has supplied an example that
shows
how to use mms to maintain symbol vectors. I am passing this on you in
hopes
that it might be a helpful addition to the info that you already have.
Karen
Subj: shareable images form c++ sources, note 3426.*, AXP-DEVELOPER
Hi Karen,
I just read you entries in the AXP-Developer notes conference about linking
shareable images from c++ sources. I know I'm late, you just asked for feedback
from the partner, but I have a small example with mms that might help. It shows
how to use mms to maintain symbol vectors for functions. It's not perfect but
it may help the partner to create his own makefile or command procedure.
Regards,
Hartmut
# descrip.mms:
.first :
@- def/nolog/job share sys$disk:[]share
main : main.exe
@- ! no action
main.exe : main.obj main.opt share.exe
$(link) $*, $*/opt
main.opt :
open/write outfile $@
@- write outfile "share/share"
@ close outfile
share.exe : share.obj share.opt
$(link)/share $*, $*/opt
share.opt : share.obj share.sym share.edt share.ref
@ anal/obj $* /out=a.tmp
@ search a.tmp symbol: /out=b.tmp
@ search b.tmp $/match=nor /out=c.tmp
@ sort c.tmp z.tmp
@ diff share.ref z.tmp/sep=rev/nonumb/match=1 /out=d.tmp
@ search/nowarn d.tmp symbol: /out=e.tmp
@ append e.tmp share.sym
@ new= f$file("e.tmp","eof")
@ delete %.tmp;*
@ if new .ne. 0 then $ open/read infile share.gsm
@ if new .ne. 0 then $ read infile line
@ if new .ne. 0 then $ close infile
@ if new .ne. 0 then $ line= f$ext(f$loc(",",line)+1,f$len(line),line)
@ if new .ne. 0 then $ major= f$ext(0,f$loc(",",line),line)
@ if new .ne. 0 then $ minor= f$ext(f$loc(",",line)+1,f$len(line),line)+1
@ if new .ne. 0 then $ open/write outfile $*.gsm
@ if new .ne. 0 then $ write outfile "GSMATCH=LEQUAL,", major, ",", minor
@ if new .ne. 0 then $ close outfile
@ if "" .nes. f$search("share.opt") then $ del share.opt;*
@ def/user sys$output nl:
edito/edt/command=share.edt $@
share.edt :
open/write outfile $@
@ write outfile "include share.gsm"
@ write outfile "include share.sym"
@ write outfile "sub/symbol: ""/symbol_vector=(/whole"
@ write outfile "sub/""/=procedure)/whole"
@ write outfile "exit"
@ close outfile
share.sym :
.ifdef MAJOR
search/nowarn nl: "I can't use '$ create' in mms" /out=$@;$(MAJOR)
open/write outfile $*.gsm
@ write outfile "GSMATCH=LEQUAL,$(MAJOR),0"
@ close outfile
.else
@ write sys$output "-e-majreq, building from scratch, new major id required
@ write sys$output "-i-usage, mms/macro=major=<id>
@ exit
.endif
share.ref : share.sym
sort $< $@
clean :
@- purge
@- delete share.obj;, main.obj;
@- delete share.opt;, main.opt;
@- delete share.edt;, share.ref;
clobber : clean
@- delete main.exe;, share.exe;
@- deass/job share
// main.cxx
#include <iostream.h>
void fi (int i);
// extern int called;
int main (void) {
cout<< "this is main from " __FILE__<< endl;
cout<< "call fi"<< endl;
fi (4711);
cout<< "back in main"<< endl;
// cout<< called<< "calls"<<endl;
}
// share.cxx
#include <iostream.h>
static int called=0;
/* remove this comment to add a new function to the shareable image
void fd (double d) {
called++;
cout<< "this is fd from " __FILE__<< endl;
cout<< "got "<< d<< endl;
}
*/
void fi (int i) {
called++;
cout<< "this is fi from " __FILE__<< endl;
cout<< "got "<< i<< endl;
}
void ff (float f) {
called++;
cout<< "this is ff from " __FILE__<< endl;
cout<< "got "<< f<< endl;
}
--------------------------------------------------------------------------------
Digital Equipment GmbH
Software Partner Engineering
Hartmut Becker [email protected]
Freischuetzstr. 91 Telefon [49](89)9591-0
D-81927 Muenchen Telefax [49](89)9591-2220
|
| 3436.19 | all set | HYDRA::DORHAMER | | Fri May 16 1997 12:45 | 6 |
| I just called Steve to follow up. The documentation and examples that
we supplied were fine. He felt that the process was "arcane" compared
to creating DLL's on NT. He would strongly encourage that the process
be documented in the C++ documentation. He would also like to see
a tool for automating this process. I told him that I would give this
feedback to C++ engineering.
|
| 3436.20 | feedback to C++ engineering | HYDRA::DORHAMER | | Fri May 16 1997 12:52 | 24 |
| #8 16-MAY-1997 11:51:37.64
NEWMAIL
From: HYDRA::DORHAMER
To: HNDYMN::MCCARTHY
CC: DORHAMER
Subj: RE: any word back on the shareable image
documentation/examples?
Brian,
I finally called Steve Popkes to get his feedback on the shared image
documentation and examples. He said that it worked fine and he would
strongly encourage adding the information to the C++ documentation.
He also commented that the process is "arcane" compared to using DLL's
on NT. He would like to see a tool ship with C++ that would automate
this process.
Thanks again for all your help and for providing the documentation and
examples. We are still interested in adding this to our web page once
you feel that its ready for prime time.
Thanks,
Karen
|
| 3436.21 | | HYDRA::AXPDEVELOPER | Alpha Developer support | Mon Jun 02 1997 15:04 | 0
|