Conference turris::c_plus_plus

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.

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

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

>>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.

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

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

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

Sorry:

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

bjm

>> Whom should I contact?

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

bjm

>>...  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.

>>> 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).

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

>>... 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.

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
[email protected]

#!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]