Craig A. Berry wrote:
At 10:17 PM -0600 8/21/07, Mark Berryman wrote:
I recently added the modules Image::Magick and PDF::API2 to my
system. Aside from finding and building all of the prerequisites,
>> the only major obstacle I encountered was the need to build the
supporting code using /NAMES=(AS_IS,SHORTENED) and the fact that
>> Perl is not built that way.
You may also find a dependency on the IEEE floating point values, UNIX
assumes different values than VMS default even for setting IEEE.
Are there any plans on the horizon to:
Make /NAME=AS_IS the default for building Perl on VMS?
I wonder whether that would break more things than it would fix.
We've had the following configuration option for a long time:
$ @configure -"Dusecasesensitive" -"des"
and it wouldn't be that hard to make it the default. I just worry
about how many other libraries assume all upper case symbol names.
Since we generate our own linker options files, we could perhaps
create aliases to the upper case names but also provide the
mixed-case ones. That would take some digging/debugging to get
working.
Prior to the current release of DECWindows Motif, the X11 libraries are
all upper case. Some of that got fixed for the release that comes with
VMS 8.3, but I understand it is a work in progress.
I think that the LDAP, Kerberos, and OpenSSL libraries may also still be
in all upper case. PTRs have been filed to get that fixed, but I do not
know their status.
Does -Dusecasesensitive also include making the names CRC shortened?
I need to find the script that generates the option file to see how hard
it would be to generate the aliases. For the main part of perl right
now, we should not have to worry about CRC shortening as all symbols are
the right length.
But that brings us also to the issue of what should the "official"
binary interface to Perl on VMS?
Threaded or unthreaded?
32 bit or 64 bit?
IEEE or DFLOAT
Symbols are the easiest to resolve, but the other options change the
binary interface. The CRTL solves this with multiple entry points for
each routine, using mangled names selected by the compiler or the runtime.
Use the C compiler to shorten names rather than the code Perl uses
currently?
The suggestion has come up before, and it's a good one. The problem
as I understand it is that we have to know what the symbol name is
going to be at the time we translate XS into C. So we'd have to
replicate the name mangling the C compiler does. It's some kind of
polynomial that is not documented formally but can be scrounged from
newsgroup posts probably. It needs to be implemented in pure Perl
because of how early in the build process it's needed and because it
needs to work in miniperl where dynamic extensions can't be loaded.
I am not sure that Perl needs to care about the name mangling if we
implement it in the dl_vms.c. Perl can pass the full length exact case
symbol name, and then dl_vms.c can try it using the following algorithm:
1. Try exact case and length.
2. Try all uppercase and exact length.
3. Try exact case and CRC shortened.
4. Try uppercase and CRC shortened.
5. Try exact case truncated.
6. Try uppercase truncated.
At the last I knew, this was the fix that was discussed to be put into
the CRTL for dlsym().
The 2nd most common obstacle I encountered was the number of times
that the "perl makefile.pl" command generated an MMS file that contained
Unix syntax (e.g. -W switches in the CC command line). Unfortunately, my
knowledge of the internals of the Perl extension build process is
essentially non-existant so I do not know where to fix this other than
editing the MMS file after it is created. What would be the best way to
get this addressed?
Has this any relationship to the module build failures in blead? Or to
Makemaker?
I have not yet tried to build Perl using GNV, now that GNV should be
able to run the configure script..
Well, the easiest way in any given case is to fix the broken
Makefile.PL that assumes everyone is using gcc on UNIX. So, for
example, when Image::Magick's Makefile.PL does the following:
# C compiler flags (e.g. -O -g)
'CCFLAGS' => "$Config{'ccflags'} -g -O2 -Wall -W -pthread",
we'd have to translate the gcc options into something, so -O2 would
become /OPTIMIZE=whatever, etc. And of course that would need to be
conditionalized for VMS. A better solution in this case would be to
just remove the non-standard options -- they can always be added from
the command line if you want them, and I don't think they'll do you
any good if Perl itself doesn't already have them (for example,
building an extension with threads means nothing if the main image
isn't built with threads).
The CC wrapper in GNV will translate most of them correctly. It may be
a matter of getting MMS/MMK to use it instead of the C compiler directly.
In many cases, it is better to simply ignore many of the UNIX build
options entirely and allow a set of VMS ones to be used instead.
A more general solution would try to parse all the options, translate
the ones we can, and ignore the ones we can't. This would be more
or less the GNV approach. We currently handle -I for the compiler
and -L for the linker, so there is precedent.
Yes. That seems to be in module build.
-John
[EMAIL PROTECTED]
Personal Opinion Only
