On Jun 24, 2010, at 5:54 PM, John E. Malmberg wrote:
On 6/24/2010 2:03 PM, Mark Berryman wrote:
Link /NoTrace/NoMap/Trace/Exe=MINIPERL.EXE miniperlmain.obj,
libperlmini.olb/Library/Include=globals ,[]crtl.opt/Options
%ILINK-W-NOSUCHMOD, module GLOBALS not found
in library USERS:[BERRYMAN.PERL-5_12_1]LIBPERLMINI.OLB;1
%ILINK-W-NUDFSYMS, 8 undefined symbols:
%ILINK-I-UDFSYM, lib$find_image_symbol
%ILINK-I-UDFSYM, lib$initialize
%ILINK-I-UDFSYM, lib$rename_file
%ILINK-I-UDFSYM, sys$filescan
%ILINK-I-UDFSYM, sys$get_security
%ILINK-I-UDFSYM, sys$getdviw
%ILINK-I-UDFSYM, sys$set_security
%ILINK-I-UDFSYM, sys$sigprc
Those undefined symbols should be easy to fix, they just need to be
declared in upper case in the source file. I am trying to remember
if I submitted a patch to do that before.
Unfortunately the system header files for defining those routines is
generated by a program that has not been updated to properly
generate function prototypes from the source file it uses. That is
why I never use that file, and instead manually prototype the system
services. The proper prototypes make several common programming
errors to be detected by the compiler.
Well, whatever the "proper" prototypes are, several of the prototypes
in [.vms]vms.c have type mismatches compared to the prototypes in the
system-supplied headers. The only reason we don't see the mismatches
all the time is because the system headers have #defines to make the
routine names upper case as seen by the compiler and vms.c doesn't.
If we add #defines like that in vms.c, then the compiler sees that the
functions are the same ones already prototyped in lib$routines.h or
starlet.h and knows that we're providing incompatible prototypes.
So I think these home-rolled prototypes have to go. It's the system's
job to prototype system-supplied routines in the system-supplied
headers. Trying to second guess that just makes the code more
fragile. I don't know of any way to undo a prototype the compiler has
already seen, and I'm not about to take on the maintenance burden of
keeping up our own versions of starlet.h and lib$routines.h so that we
can prevent the compiler from seeing the system-supplied prototypes.
The code that currently uses LIB$FIND_IMAGE_SYMBOL needs to be
updated to do the following:
1. If the symbol is over 31 characters:
a. Try loading it in exact case but CRC shortened the way the
C compiler does.
b. Try loading it in upper case but CRC shortened the way the
C compiler does.
c. Try loading it in exact case but truncated to 31 characters.
d. Try loading it in upper case but truncated to 31 characters.
2. For symbols 31 characters or less, try looking for it in exact case
first and then in all upper case.
We have complete control over how the symbols are created at build
time. I can't see any good reason to add this level of complexity and
processing at run time.
________________________________________
Craig A. Berry
mailto:craigbe...@mac.com
"... getting out of a sonnet is much more
difficult than getting in."
Brad Leithauser
