I hadn't encountered 'mangling' till installing CXX but I'm having some problems linking a FORTRAN program which calls a C++ function which then uses GETJPIW
(I've coded quite a lot of FORTRAN in the past but am trying to learn C++ and also use the system services (which I suspect are a good 'selling point' for OpenVMS) which is fine until - like the Cadillac in Johnny Cash's song - I try to fit them together.:
$ @process_watch.com
%LIBRAR-W-COMCOD, compilation warnings in module GET_ALL_PROCESSES file SYS$SYSD
EVICE:[USER.DAVE.PROC_WATCH]get_all_processes.OBJ;6
%LINK-W-NUDFSYMS, 1 undefined symbol:
%LINK-I-UDFSYM, GET_ALL_PROCESSES
%LINK-W-USEUNDEF, undefined symbol GET_ALL_PROCESSES referenced
in psect $LINK$ offset %X000001C0
in module GET_PROCESSES file SYS$SYSDEVICE:[USER.DAVE.PROC_WATCH]PROCESS
_WATCH.OLB;1
%DCL-W-SKPDAT, image data (records not beginning with "$" ) ignored
After trying a few things llike shortening the function name GET_ALL_PROCESSES to GETPROCS and adding 'underscores', I searched the object file produced by the CXX and found the 'mangled' version of my function name
and put this in my Fortran routine
EXTERNAL GETPROCS__XPCPCIIIIIL
INTEGER GETPROCS__XPCPCIIIIIL ! C++ function
- this links ok.
- Obviously this isn't the way FORTRAN should Call C++, so I wondered if anyone has some advice?
I found this recommendation for the C++ function:
extern "C"
int GETPROCS ( char, char, int, int, int, int, int, long int); - but it didn't seem to help
Edited by somersdave on April 22 2012 10:52
To support function overloading in C++, the C++ compiler generates a different function entry point for each possible set of parameters. Since each entry point must be unique, the C++ compiler encodes the parameter types into the process name.
On VMS, it then may hit the 31 character limit on function names, so it will then calculate a CRC for the original name, and then truncate the symbol name with the CRC result appended to it.
If you look at the symbols produced by C++ compilers on other platforms, you will usually see the type names for each of the arguments appended to the original routine name.
Now generally for all platforms, if you want to have a routine compiled by C++ accessed by a different language, you need an entry point that does not have the parameter types encoded into it.
That is what the extern "C" declares.
The same is true when you are declaring prototypes for non C++ routines to be called by C++ code, you have to use the extern "C" to tell the compiler not to encode the data types into the actual symbol being called.
malmberg August 04 2022 No more VAX hobbyist licenses.
Community licenses for Alpha/IA64/X86_64 VMS Software Inc.
Commercial VMS software licenses for VAX available from HPE.
ozboomer July 20 2022 Just re-visiting.. No more hobbyist licenses? Is that from vmssoftware.com, no 'community' licenses?
valdirfranco July 01 2022 No more hobbyist license...sad
mister_wavey February 12 2022 I recall that the disks failed on the public access VMS systems that included Fafner
parwezw January 03 2022 Anyone know what happened to FAFNER.DYNDS.ORG?
I had a hobbyist account here but can longer access the site.
gtackett October 27 2021 Make that DECdfs _2.1A_ for Vax
gtackett October 27 2021 I'm looking for DECdfs V2.4A kit for VAX.
Asking here just in case anyone is still listening.
MarkRLV September 17 2021 At one time, didn't this web site have a job board? I would love to use my legacy skills one last time in my career.
malmberg January 18 2021 New Hobbyist PAKs for VAX/VMS are no longer available according to reports. Only commercial licenses are reported to be for sale from HPE
dfilip January 16 2021 Can someone please point me to hobbyist license pak? I'm looking for VAX/VMS 7.1, DECnet Phase IV, and UCX/TCPIP ... have the 7.1 media, need the license paks ... thanks!
- I try to fit them together.:
