Re: Perl 5.12.1 build report

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

"... getting out of a sonnet is much more
  difficult than getting in."
                  Brad Leithauser