On 6/24/2010 2:03 PM, Mark Berryman wrote:
On Jun 24, 2010, at 12:08 PM, Craig A. Berry wrote:
4. Too many extensions like to use labels that differ only in
case or reference external libraries that are built with
/names=(as_is,short). By editing 3 include files in Perl, extern.h,
perl.h, and xsub.h in PERL_ROOT:[.LIB.VMS_arch.5_12_1.CORE], to set the
NAMES pragma to uppercase at the beginning of the file and restore it at
the end, I am able to modify the generated DESCRIP.MMS file of the
extension being built to include the names=(as_is,short) switch and
build the extension without difficulty. I believe this would be worth
doing as part of the standard installation. It would also be nice if
there were an option to add this switch into the generated DESCRIP.MMS
automatically.
You can get /NAMES=AS_IS by configuring the Perl build with:
$ @configure -"Dbe_case_sensitive=Y" -"des"
Unfortunately pragma names are not standardized. While they may end up
meaning the same thing on different compilers, nothing enforces that, so
pragmas must be wrapped with a test for the compilers that they are
known to be valid on that may be used for the compilation. It gets
messy fast.
I tried this once. The build fails to even build miniperl. Here I
can reproduce this fairly quickly...
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.
<snip>
All this does is tell MMS that, when processing a .C file into a
.OBJ file, check to see if the filename is uppercase. If not, rename it so it
is. The syntax at COMPLETE_APPLICATION tells MMS to compare the module
in the library to the source and rebuild it if it has changed but it
only works if the module names in the library are all uppercase
(otherwise it aborts with an "action did not update target" error).
Would this help make Perl any more independent of the type of build disk
being used?
We need a solution for building on ODS-5 that results in the files and
directories having the same case as on a Unix system. This stopped me
from testing with Perl set for exact case filenames.
However, I have not found out how to get MMS to accept a lower case
module name into a library. It seems to be expecting the module name to
be uppercase. So putting in a rename in MMS files created on ODS-5
volumes may be needed. I thought that MMK did not have this issue.
I am currently using DEC MMS to build GNV bash and I ran into that
issue. The mkbuiltins utility is only creating lowercase filenames, and
I do not plan to look at changing it. I ended up setting the following
rule:
# MMS requires that the generated name be in upper case to generate an
# upper case module name for the librarian.
.def.c
@ mkbuiltins :== $prj_root:[]mkbuiltins.exe
$ set def prj_root:[.builtins]
$ source = f$parse("$(MMS$SOURCE)",,,"NAME")
$ source_u = f$edit(source, "UPCASE")
$ mkbuiltins "-D" ./builtins/ 'source'.DEF
$ if f$getsyi("ARCH_TYPE") .ne. 1 then set proc/parse_style=extended
$ if f$getsyi("ARCH_TYPE") .ne. 1 then rename 'source'.C 'source_u'.C
$ set def prj_root:[-]
So what ever we do to make it build, we will need to do something to
make sure that all files and directories for running the self tests end
up in the correct case on ODS-5 volumes.
xsubpp should do its own name shortening, but that can cause
trouble with external libraries. I'd consider making /NAMES=(AS_IS,SHORTENED)
the default for 5.14.0, but need to give some thought to what will break.
xsubpp seems to shorten names declared in the XS file but it doesn't
seem to touch names that are simply references to something external. In
the list of extensions I gave, there are several instances where some
names are shortened and others are not. This is probably a good thing
because I don't know of anything else that uses the same shortening
algorithm used in Perl. By using /names=(as_is,short) in the extension
build process, the names shortened by xsubpp are ignored but the names
referencing the external library get shortened the same way they were
when the library was built.
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.
The CRTL dlsym() needs the same fix.
The difficulty with compatibility is why I suggested continuing to
build Perl as all uppercase but modifying the Perl include files to add
a names pragma. That way, it doesn't matter how the program referencing
Perl is being built, it still gets all of the Perl references in the
correct case. It also means that the MMS files built by makefile.pl when
building extensions could include /names=(as_is,short) by default. The
only remaining issue I know of then becomes whether you include a
statement like /define="boot_XML__Parser__Expat=BOOT_XML__PARSER__EXPAT"
in the build file or handle it in the dlsym code.
Perl on VMS currently does not use dlsym().
This is something that should be looked at, as latest C compiler
standard no longer allows compilers to truncate the symbols at 31
characters as previous standards have, and programmers are being more
verbose in their names.
Once I get GNV building and running properly on both VAX and Alpha, I
will probably start looking at applying the lessons I learn from that on
Perl. But right now I do not have time to devote to keeping up to date
with blead perl.
-John
wb8...@qsl.network
Personal Opinion Only
