[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

3483.0. "C++/VMS documentation missing for creating shareable images" by VNASWS::WILFRIED (Wilfried Bergmann, Austria) Mon Mar 10 1997 14:02

The new "Using DEC C++ on OpenVMS Systems" manual, dated April 96, doesn't
have the section on how to create shareable images, that was present earlier,
e.g. in the June 93 one: "3.3 Creating OpenVMS Shareable Images with C++"

Where can this information be found today?

Is the process described in the older manual still correct?

Thanks!

/wb
T.RTitleUserPersonal
Name
DateLines
3483.1specific issues? HNDYMN::MCCARTHYA Quinn Martin ProductionMon Mar 10 1997 15:137
The information in the older manual was, at best, misleading.  Are there 
specific questions you have?  The latest documentation points you at the 
OpenVMS Linker manual for more information, which is where the bulk of the
information that was in the older books came from - but we are not in the 
business of documenting the OpenVMS linker utility.

Brian J.
3483.2NotedDECCXX::AMARTINAlan H. MartinMon Mar 10 1997 18:085
Re .0:

I have logged a problem	report to document the process of creating a sharable
image containing DEC C++ code on VMS.
				/AHM/THX
3483.3specific issues; re .1VNASWS::WILFRIEDWilfried Bergmann, AustriaTue Mar 11 1997 07:3517
I think the information available in the linker manual is not sufficient,
in particular for C++.

The hint to create an object library to use a LIB/LIST command to get a
list of the global (mangled) names, the need to create a pointer macro file
for global data ponters (which I was _not_ aware of, that this would be
required) is valuable information! And I think, we could/should even do
better in giving a concrete example in the C++ manual.

The customers complaint is, that the whole process of creating shareable
images is rather awkward compared to creating DLL's under windows. He has
to support a significant number of RTL's, both on VAX and now also on Alpha.
He wants to have only one set of source files. So he asked me wether we, DEC
internaly have some tools to help maintain large shareable images (with global
data and entry points in the 100's).

/wb
3483.4Its there somewhere...HNDYMN::MCCARTHYA Quinn Martin ProductionTue Mar 11 1997 09:4730
>>I think the information available in the linker manual is not sufficient,
>>in particular for C++.

Correct.  I could not find the specific section in the hard copy I had in 
front of me.  The information is there, somewhere, I just can't find it.  
When I do, I'll post it.

>>The customers complaint is, that the whole process of creating shareable
>>images is rather awkward compared to creating DLL's under windows. 

Never having had done DLL's, I can't comment.  The OpenVMS Alpha model is 
much simpler.

>>He has
>>to support a significant number of RTL's, both on VAX and now also on Alpha.
>>He wants to have only one set of source files. So he asked me wether we, DEC
>>internaly have some tools to help maintain large shareable images (with global
>>data and entry points in the 100's).

There are no automatic processes that are in wide spread use.  TPU used a
script which created its symbol_vector options file off of its transfer.mar
file, DECC$SHR engineers are told "when you add it here, add it there" as
are the Class Library engineers.  The tests would catch the errors (added
to one but not the other).  Those are the three projects that I have worked
with that have common sources for both OpenVMS Alpha and OpenVMS VAX.

The OpenVMS group build procedures have a utility which verifies that the 
entry points do not change.

Brian J.
3483.5tools? re .4VNASWS::WILFRIEDWilfried Bergmann, AustriaTue Mar 11 1997 14:2310
Brian,

>The OpenVMS group build procedures have a utility which verifies that the 
>entry points do not change.

Is there any chance that I could get my hands on this utility and give
it to the customer (of course without any support/warrenty)? Whom should
I contact?

/wb
3483.6Microsoft has it nowDECCXX::AMARTINAlan H. MartinTue Mar 11 1997 14:2516
Re .4:

>>The customers complaint is, that the whole process of creating shareable
>>images is rather awkward compared to creating DLL's under windows. 
>
>Never having had done DLL's, I can't comment.  ...

It's trivial.  As I recall, you tell the environment you're building a DLL
instead of an object library, you mark the appropriate universals with the
__declspec(dllexport) declaration qualifier, and you're done.


>...  The OpenVMS Alpha model is much simpler.

Not compared to the market leader.
				/AHM
3483.7clarifyHNDYMN::MCCARTHYA Quinn Martin ProductionTue Mar 11 1997 15:077
>>>...  The OpenVMS Alpha model is much simpler.

Sorry:

The OpenVMS Alpha model is much simpler than the OpenVMS VAX model.

bjm
3483.8cross-referenceHNDYMN::MCCARTHYA Quinn Martin ProductionTue Mar 11 1997 15:155
>> Whom should I contact?

I'd ask in the vaxaxp::vmsnotes conference.

bjm
3483.9VAXCPU::michaudJeff Michaud - ObjectBrokerTue Mar 11 1997 17:387
>>...  The OpenVMS Alpha model is much simpler.
> Sorry:
> The OpenVMS Alpha model is much simpler than the OpenVMS VAX model.

	"Much" is too strong a word.  It's simpler in that you don't
	need any macro code, but you still need to know which mangled
	symbols are data symbols and which are procedure entry points.
3483.10VAXCPU::michaudJeff Michaud - ObjectBrokerTue Mar 11 1997 17:4617
>>> The customers complaint is, that the whole process of creating shareable
>>> images is rather awkward compared to creating DLL's under windows. 
>> Never having had done DLL's, I can't comment.  ...
> It's trivial.  As I recall, you tell the environment you're building a DLL
> instead of an object library, you mark the appropriate universals with the
> __declspec(dllexport) declaration qualifier, and you're done.

	Well almost that simple.  You want __declspec(dllexport) only
	when you are declaring the function/data (or whole class) when
	you are building the library.  You want it to be __declspec(dllimport)
	at the time the users of that library include your header files.

	Even if the compiler and linker folks agreed on a new object file
	record type so the compiler can tell linker which symbols to
	export, VMS will also have to solve the problem of removing the
	requirement of only finding entry points via ordinal value (ie.
	the vector tables).
3483.11TidbitsDECCXX::AMARTINAlan H. MartinTue Mar 11 1997 20:2426
Re .10:

>...  You want it to be __declspec(dllimport)
>	at the time the users of that library include your header files.

Yep, agreed.


>	Even if the compiler and linker folks agreed on a new object file
>	record type so the compiler can tell linker which symbols to
>	export, ...

[E]GSY$V_UNI ?  That's what .TRANSFER emits.
				/AHM



>... VMS will also have to solve the problem of removing the
>	requirement of only finding entry points via ordinal value (ie.
>	the vector tables).

Certainly the Macro vectors on the VAX are "merely" to implement upwards
compatibility.  However, I haven't peered underneath the hood on Alpha to see
whether the vectors there are a convention, or a requirement, and whether it's
amenable to automation from compilers.
				/AHM
3483.12VAXCPU::michaudJeff Michaud - ObjectBrokerTue Mar 11 1997 20:5647
>>... VMS will also have to solve the problem of removing the
>>	requirement of only finding entry points via ordinal value (ie.
>>	the vector tables).
> Certainly the Macro vectors on the VAX are "merely" to implement upwards
> compatibility.  However, I haven't peered underneath the hood on Alpha to see
> whether the vectors there are a convention, or a requirement, and whether it's
> amenable to automation from compilers.

	I just went through all the relevant docs last week trying to
	figure out an easier way (there isn't that I could find :-)
	and from what I read, the VAX transfer vector table is not
	"required" per se.  I had meant to say for "upwards compatiblity"
	which I consider to be a given.

	BTW, while there is no macro transfer code on AlphaVMS, it's still
	based on the ordinal position that a symbol was specified in the
	SYMBOL_VECTOR option list.  You change the ordering, which, baring
	any creative hacks, is a given if you rename a source module,
	or add new global symbols, and you've lost backwards compatiblity
	(as the compiler (or linker) will generate (or read) the exported
	symbols in a different order).

	On Digital UNIX, NT, and some other platforms, the run-time loader
	resolves symbols with a symbol table in the shared library or dll.
	Backwards compability is maintained as long as you have removed
	any entry points that are still referenced by applications, etc
	linked with the last version of the library.  NT (Windows) does
	give the option of specifing ordinal values for entry points
	if you wish, but not required.

	I'm guessing it's done the way it is on VMS because VMS is from
	the days of the 780, and to do any symbol resolution at run-time
	would surely be a significant performance hit.  Digital UNIX
	compromises.  It does symbol resolution/fixup only if it appears
	it has to.  When you link against the shared library, the linker
	stores not only the name of the library in the header of the image
	being created, it stores checksums and/or timestamps from the
	shared library.  If at runtime the library is loaded at it's prebuilt
	base addresses, and the checksum/timestamps match, no fixup is needed.

	VMS could add support for run-time symbol resolution without removing
	the existing mechanisms, and provide a linker option.  While some
	image startup performance may be sacrificed building a shareable
	library with this option, for developers who are willing to
	scarifice, that when using languages whose global/exported symbols
	are mangled (such as C++), the savings in development/maint. costs
	would be worth it.
3483.13Building the Symbol Vector for alphasNETRIX::"ReeseW@mail.dec.com"Bill ReeseThu Mar 13 1997 02:3682
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.

Bill Reese
ReeseW@mail.dec.com

#!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);

[Posted by WWW Notes gateway]