|
|
|
|
|
|
| Author |
Message |
Craig A. Berry
*nix forums Guru Wannabe
Joined: 27 May 2005
Posts: 143
|
 Posted: Fri May 27, 2005 4:12 pm Post subject:
Re: Changing osname or ^O from VMS.C at startup?
|
|
|
On Tuesday, February 15, 2005, at 02:21PM, John E. Malmberg <malmberg@Encompasserve.org> wrote:
| Quote: | It appears that the VMS specific file name behavior is tied to many perl
scripts that are checking the ^O for 'VMS'.
What I would like to investigate is having a option where a symbol or
logical name could be used by the init and pre-init code in VMS.C
to change the ^O to report 'GNV'. That same feature would also cause
the DECC feature settings to go to full UNIX/POSIX filename compatibility
mode.
|
The global PL_osname is set in S_init_predump_symbols in perl.c, which is called from S_parse_body when a Perl script is compiled. If you put in your own value in start-up code, I'm pretty sure it will get overwritten later. You could stick some code in S_init_predump_symbols to check for a logical name and reset accordingly. That might be a little dangerous since we don't really know what side effects there might be to dynamically changing the OS name.
If you can live with configuration time changes, look for
$ osname = F$EDIT(F$GETSYI("NODE_SWTYPE"),"COLLAPSE")
in configure.com and modify it to say whatever you want.
| Quote: | In investigating why the first standard test for symlinks on perl was
failing, it turns out that the fast_abs_path() and abs_path() call VMS
specific code including using rms calls to return the path. This
existing code does not know how to follow a symbolic link to the
real path, and since other code calls those same routines that should
not return a real path, but the link value, a new routine would be needed
for the abs_path routines to use.
Alternatively, symbolic links virtually require UNIX/POSIX path names to
function, which means that they are most likely only to be used in a
full POSIX environment.
It looks like when Perl does not recognize the value of ^O, it defaults
to POSIX/UNIX behavior on file handling.
I have not found out yet how to read or change the value of ^O from C, as
it seems to only be set by config.pm, and I am not sure if config.pm is
used after Perl is built.
If anyone has any suggestions on an easy way to do this, please let me
know.
Thanks,
-John
wb8tyw@qsl.net
Personal Opinion Only
|
|
|
| Back to top |
|
 |
John E. Malmberg
*nix forums Guru Wannabe
Joined: 30 May 2005
Posts: 264
|
| Posted: Fri May 27, 2005 4:12 pm Post subject:
Re: 24318 warnes on OpenVMS V7.2
|
|
|
[only monitoring vmsperl list]
Abe Timmerman wrote:
| Quote: | Hi,
I still can't build bleadperl on the VAX (without /ignore=warning):
CC/DECC /Include=[]/Standard=Relaxed_ANSI/Prefix=All/Obj=GLOBALS.obj/NoList/
Define=PERL_CORE GLOBALS.C
%VCG-W-BADPSECT, The program section(psect) specified by this statement has
conflicting 'nowrite' attributes with another definition
of the same program section.
At line number 1002 in BLDROOT:[000000]PERLAPI.H;1.
|
That looks like a serious programming error, any idea what is causing it?
It looks like it is saying that the same storage has been declared both
as readonly and as writable at the same time.
If this is VAX specific, it looks like something in an #ifdef VAX
section is not coded correctly.
-John
wb8tyw@qsl.net
Personal Opinion Only |
|
| Back to top |
|
|
Veeresh
*nix forums beginner
Joined: 27 May 2005
Posts: 1
|
| Posted: Fri May 27, 2005 4:12 pm Post subject:
RE: Unable to Create perl 'XS' interface static Library on OpenVMS
|
|
|
Hi Craig,
Thanks for the information.
Actually I am not getting oc_lib_tool_xs.olb, but getting
oc_lib_tool_xs.opt. I want to link XS interface library to my application,
so that my application can run perl scripts from C++ which in turn uses XS
interface calls. Is there anything needs to be added in Makefile.PL so that
mms can generate oc_lib_tool_xs.olb instead of oc_lib_tool_xs.opt?
Thanks & Regards,
Veeresh
-----Original Message-----
From: Craig Berry [mailto:craigberry@mac.com]
Sent: Monday, April 11, 2005 11:23 PM
To: vanami@india.hp.com
Cc: vmsperl@perl.org
Subject: Re: Unable to Create perl 'XS' interface static Library on OpenVMS
On Monday, April 11, 2005, at 09:42AM, Veeresh <vanami@india.hp.com> wrote:
| Quote: | Hi All,
Could you please clarify the following query:
I have attached Makefile.PL and the 'DESCRIP.MMS' file generated out of
Makefile.PL by perl with 'perl Makefile.PL' command.When I do 'mms',
then it finally generate 'XXXX.OPT', but I actually wanted is static
library.
A. What is the extenstion of static library file in OpenVMS?
B. How to generate static Library?
C. Is there any way to convert .OPT file to static Library?
|
An .OPT file is a linker options file. There's lots of info on this in the
OpenVMS Linker Utility manual, and some of your questions might also be
answered in the OpenVMS Librarian Utility Manual; both are available from
<http://www.hp.com/go/openvms/doc>.
The nomenclature on VMS for static vs. dynamic libraries is that a static
library is simply called an object library and by default has an extension
of .OLB and a dynamic library is called a shareable image and by default has
an extension of .EXE. Object libraries are created by the librarian, and
shareable images are created by the linker. There is no sense in which a
linker options file can be "converted" into an object library; it contains
directives the linker uses to generate images (both executable images and
shareable images).
A normal build of an XS extension will create an object library, and then it
will use the linker to create a shareable image from that. Do you not get
an oc_lib_tool_xs.olb? And by the way, why do you want one? It's not
needed once the shareable image is created. |
|
| Back to top |
|
|
Craig A. Berry
*nix forums Guru Wannabe
Joined: 27 May 2005
Posts: 143
|
| Posted: Fri May 27, 2005 4:12 pm Post subject:
Re: Unable to Create perl 'XS' interface static Library on OpenVMS
|
|
|
On Monday, April 11, 2005, at 09:42AM, Veeresh <vanami@india.hp.com> wrote:
| Quote: | Hi All,
Could you please clarify the following query:
I have attached Makefile.PL and the 'DESCRIP.MMS' file generated out of
Makefile.PL by perl with 'perl Makefile.PL' command.When I do 'mms', then it
finally generate 'XXXX.OPT', but I actually wanted is static library.
A. What is the extenstion of static library file in OpenVMS?
B. How to generate static Library?
C. Is there any way to convert .OPT file to static Library?
|
An .OPT file is a linker options file. There's lots of info on this in the OpenVMS Linker Utility manual, and some of your questions might also be answered in the OpenVMS Librarian Utility Manual; both are available from <http://www.hp.com/go/openvms/doc>.
The nomenclature on VMS for static vs. dynamic libraries is that a static library is simply called an object library and by default has an extension of .OLB and a dynamic library is called a shareable image and by default has an extension of .EXE. Object libraries are created by the librarian, and shareable images are created by the linker. There is no sense in which a linker options file can be "converted" into an object library; it contains directives the linker uses to generate images (both executable images and shareable images).
A normal build of an XS extension will create an object library, and then it will use the linker to create a shareable image from that. Do you not get an oc_lib_tool_xs.olb? And by the way, why do you want one? It's not needed once the shareable image is created. |
|
| Back to top |
|
|
John E. Malmberg
*nix forums Guru Wannabe
Joined: 30 May 2005
Posts: 264
|
| Posted: Fri May 27, 2005 4:12 pm Post subject:
OpenVMS behavior options - (was: [ANNOUNCE] ExtUtils::MakeMaker 6.26_01)
|
|
|
[Replies set to vmsperl@perl.org, as it is the only list I am subscribed to]
Michael G Schwern wrote:
| Quote: | On Tue, Mar 29, 2005 at 02:43:42PM -0500, PPrymmer@factset.com wrote:
But in any case the tests all pass on VMS with or without that patch in place.
Now that's unexpected. VMS works but Solaris didn't.
|
Which makes this a point to bring up some VMSisms that some people
including OpenVMS Perl programmers may not be aware of.
There are also some changes that I am currently testing on the side that
will potentially affect any Perl module that has OpenVMS specific code
in it. They can be turned on and off as needed, but I would like to be
able to eventually pass the self tests supplied with Perl with these
features set.
MM_UNIX is one of the ones potentially affected. I am not yet good
enough at reading Perl scripts to tell.
Some background:
The behavior of the OpenVMS C runtime library is dependent on feature
logicals which control how many things work.
But with these feature logicals set, which perl scripts can check
through the ENV{} operator, the C RTL features of OpenVMS can change to
behaving more like UNIX and less like traditional OpenVMS.
The way that Perl is currently implemented, changing these feature
logicals from their default is almost certainly guaranteed to have bad
results. This is because in many cases some of the C filename parsing
is bypassed for the support of older versions of OpenVMS.
As part of what I am doing to implement Symbolic link support on
OpenVMS, it requires that to use Symbolic links, the C feature logicals
and VMS environment settings need to be honored by the PERL executable.
The plus side of this is that it will allow Perl on OpenVMS 8.2 (Alpha
and I64), and to a lesser extent older versions of OpenVMS on Alpha to
run many scripts that are expecting UNIX behavior that currently will
not run.
Many of these scripts are used in the building of programs on UNIX, and
having them work unmodified on OpenVMS would be goodness for all.
The unfortunate side effect is that when these features are set to a
UNIX compatible mode, any perl scripts that are expecting traditional
VMS behavior with out requesting a filename converted explicitly to VMS
format on VMS may break.
I hope that you will pardon my lack of Perl Script programing experience
on these explanations, and for brevity, I am simplifying things, but
some of the things that are optional are:
1. Treat all filenames as UNIX syntax. No VMS file specifications are
permitted.
2. Accept VMS or UNIX file specifications, but always report them as
UNIX type.
With either the above two enabled, the ".dir" on OpenVMS directories
vanishes from returned file specifications, which may be something that
impacts MM_UNIX as noted above. Also unless a VMS specific conversion
is requested, a returned file is likely to be in UNIX format and as
noted below in the correct case, and also may include UNICODE or other
characters that normally are not in a VMS file specification.
It certainly affects the standard tests that are supplied with Perl.
3. Case preserved filenames. Filenames will be created with the case
that the application specified them in and reported that way. This
requires that the files are on an ODS-5 file system or later.
This also affects the standard tests.
4. Case sensitive filenames. Unlike the others, this is not set by a
feature logical, but a VMS environment setting. I noticed in Perl that
it was able to inquire if a platform was case sensitive, and I changed
my local copy of Perl to report the process setting that is currently in
effect. I have not tested that mode yet. This also requires ODS-5
filesystem or later.
In my current development phase, these feature settings are only checked
at the startup of perl, and changing the ENV{} after that point may have
strange side effects.
There are some others, like the handling of umask() which can be
predicted or affected by the ENV{} for that value.
Also for the OpenVMS C runtime to effectively work with Symbolic links,
the option of 2 above needs to be set, and effectively at least the
option of 3 above also.
I have also noticed that some Perl scripts are assuming that "/" is a
directory separator for things like ENV{'HOME'} and 'PERL5DB'. When the
mode 1 or 2 above is set, those will work on OpenVMS, where now they do not.
-John
wb8tyw@qsl.net
Personal Opinion Only |
|
| Back to top |
|
|
PPrymmer@factset.com
*nix forums beginner
Joined: 08 Jul 2005
Posts: 21
|
| Posted: Fri May 27, 2005 4:12 pm Post subject:
Re: 5.8.6 - t/lib/vmsfspec.t missing from manifest.
|
|
|
Craig Berry <craigberry@mac.com> wrote on 03/15/2005 11:38:18 AM:
| Quote: | On Tuesday, March 15, 2005, at 08:56AM, John E. Malmberg
malmberg@Encompasserve.org> wrote:
Is there a perl script that will identify all files that are present in
the unpacked directory except for the ones in the manifest or where
generated by the build procedure?
Test::Smoke may have something like that. In general, though, for the
core
build we need to check the manifest before we have Perl, so it's done in
DCL
in configure.com.
|
Here is the inverse of what you requested: list files not unpacked
but in the MANIFEST file. It takes care of everything except for the
multiple period files (that vmstar.exe and configure.com already have
solutions for) This is run from an unpacked perl 5.8.6 source tree
on an ODS-2 volume:
$ perl -lane "print if ! -e $F[0]" MANIFEST
Changes5.8.2 Differences between 5.8.1 and 5.8.2
Changes5.8.3 Differences between 5.8.2 and 5.8.3
Changes5.8.4 Differences between 5.8.3 and 5.8.4
Changes5.8.5 Differences between 5.8.4 and 5.8.5
Cross/Makefile.SH.patch Cross-compilation
vos/config.alpha.def definitions used by config.pl
vos/config.alpha.h config.h for use with alpha VOS POSIX.1
support
vos/config.ga.def definitions used by config.pl
vos/config.ga.h config.h for use with generally-available
VOS POSIX.1 support
If you wanted to also take care of the multi period filenames
there are several approaches. Here is one that still (barely)
fits on one line that exploits the File::Basename::fileparse()
routine:
$ perl "-MFile::Basename" -lane "if(!-e
$F[0]){($a,$d,$c)=fileparse($F[0]);@f=split(/\./,basename($a));$f=shift@f;$_=
""$d$f."".join'_',@f; print if !-e}" MANIFEST
So to obtain what you want you might want to have
a script run File::Find over the source tree and
compare the list of all files returned to a list
of files in the manifest that is built up from
one of the above algorithms.
I hope that helps.
Peter Prymmer |
|
| Back to top |
|
|
Thomas R Wyant_III
*nix forums beginner
Joined: 08 Feb 2005
Posts: 6
|
| Posted: Fri May 27, 2005 4:12 pm Post subject:
Re: Module::Install and portability?
|
|
|
Craig Berry <craigberry@mac.com> wrote on 03/14/2005 01:31:01 PM:
SNIP!
| Quote: |
Yes, it should, but so should blib. I'm not convinced this is the
real issue, but not sure when I'll get a chance to dig into it myself.
|
Maybe that's why I didn't get anywhere pursuing it. But I remember not
being able to find modules that were in fact available (if you held your
tongue right!).
Shoulda pursued it on VMSPerl when it happened. Sorry. Maybe, rather than
lamenting about the opportunity I lost, the question is:
Has anyone gotten Module::Install to work under VMS? Or has anyone _not_
been able to get it to install?
Tom
This communication is for use by the intended recipient and contains
information that may be privileged, confidential or copyrighted under
applicable law. If you are not the intended recipient, you are hereby
formally notified that any use, copying or distribution of this e-mail,
in whole or in part, is strictly prohibited. Please notify the sender
by return e-mail and delete this e-mail from your system. Unless
explicitly and conspicuously designated as "E-Contract Intended",
this e-mail does not constitute a contract offer, a contract amendment,
or an acceptance of a contract offer. This e-mail does not constitute
a consent to the use of sender's contact information for direct marketing
purposes or for transfers of data to third parties.
Francais Deutsch Italiano Espanol Portugues Japanese Chinese Korean
http://www.DuPont.com/corp/email_disclaimer.html |
|
| Back to top |
|
|
Craig A. Berry
*nix forums Guru Wannabe
Joined: 27 May 2005
Posts: 143
|
| Posted: Fri May 27, 2005 4:12 pm Post subject:
Re: 5.8.6 - t/lib/vmsfspec.t missing from manifest.
|
|
|
On Tuesday, March 15, 2005, at 08:56AM, John E. Malmberg <malmberg@Encompasserve.org> wrote:
| Quote: | It appears that the file t/lib/vmsfspec.t is missing from the manifest.
file.
|
It's generated at build time so it should not be in the manifest.
$ search [.vms]descrip_mms.template "vmsfspec.t :"/win=2
[.t.lib]vmsfspec.t : [.vms.ext]filespec.t
Copy/NoConfirm/Log $(MMS$SOURCE) $(MMS$TARGET)
| Quote: | Is there a perl script that will identify all files that are present in
the unpacked directory except for the ones in the manifest or where
generated by the build procedure?
|
Test::Smoke may have something like that. In general, though, for the core build we need to check the manifest before we have Perl, so it's done in DCL in configure.com.
| Quote: | Also it appears that magic.t is leaving a logical name "FOO" behind so
that if it is run before the INST_*.t tests, they fail as they are trying
to create a file named "FOO".
When you use the MMS script to run the tests, they are run in a subprocess
so this is not noticed.
|
Yes, there are a lot of logical name vulnerabilities. |
|
| Back to top |
|
|
John E. Malmberg
*nix forums Guru Wannabe
Joined: 30 May 2005
Posts: 264
|
| Posted: Fri May 27, 2005 4:12 pm Post subject:
Re: ExtUtils::CBuilder on VMS (was Re: Phalanxing MakeMaker)
|
|
|
Ken Williams wrote:
| Quote: |
Care to try 0.09_01, which is now hitting CPAN? I've split out the
generation of command-line switches so it can easily be overridden for
VMS. So compile() might work now. link() and friends haven't been
touched, though.
|
When Perl is run in the GNV environment, it is likely that a future
modification will be to have it use the Bash shell.
The CC command when run under the BASH shell expects UNIX syntax.
-John
wb8tyw@qsl.network
Personal Opinion Only |
|
| Back to top |
|
|
John E. Malmberg
*nix forums Guru Wannabe
Joined: 30 May 2005
Posts: 264
|
| Posted: Fri May 27, 2005 4:12 pm Post subject:
Re: [.t.io]fs.t fails with hard links on OpenVMS.
|
|
|
On Tue, 1 Mar 2005, Craig A. Berry wrote:
| Quote: | At 4:31 PM -0600 2/23/05, John E. Malmberg wrote:
To be more precise,
The test [.t.io]fs.t will only pass when hard links {d_link} if you set
the default RMS protections to be (O:RW, G:RW, W:RW).
I think that it is a cross platform bug where the test is assuming such
a default protection would be in place.
I see a lot of mode setting. I think chmod on VMS sanely refuses to
override the RMS defaults with a less secure setting, but on Unix, an
explicit setting overrides the defaults if you have privilege to do
the chmod. Someone correct me if that's not right. Probably the
best thing to do for the test is create a temporary directory with
the necessary settings and set default to it before running the test.
|
the chmod() calls are below the test that failed. The umask calls
above the test succeed.
In the umask test, Perl makes two calls to umask(), one to set it to 022
with out paying attention to it's current value, and then again with
it restoring it to 0.
It appears that Perl through the CRTL or some other reason is treating a
umask of 0 as to use RMS default protection on the file.
The documentation for the CRTL shows that it should only be using the
RMS default for the umask call only if the umask call has never been made
for that program.
It looks like this needs some more investigation to find out why the
umask value of 0 is not being honored.
| Quote: | Also the modules utils/c2ph.pl, x2p/pl will not allow Perl to be built
with hard link support unless they are modified. They are trying to
create hard links from a different base filename than exists on OpenVMS.
I think something along the lines of the following untested patch
would be more appropriate. We've already got a platform-independent
version of the filename we're creating, so we might as well use it:
--- x2p/s2p.PL;-0 Mon Aug 12 07:28:26 2002
+++ x2p/s2p.PL Tue Mar 1 13:51:29 2005
@@ -2046,9 +2046,9 @@
close OUT or die "Can't close $file: $!";
chmod 0755, $file or die "Can't reset permissions for $file: $!\n";
unlink 'psed';
-print "Linking s2p to psed.\n";
+print "Linking $file to psed.\n";
if (defined $Config{d_link}) {
- link 's2p', 'psed';
+ link $file, 'psed';
} else {
unshift @INC, '../lib';
require File::Copy;
|
What do you need to have to get hard link support included in a future perl
release once the test issue is resolved? It looks like the problem in the
test is with umask handling and not hardlink related, which means that the
umask issue should be reproducible with out hard link support on.
-John
wb8tyw@qsl.net
Personal Opinion Only |
|
| Back to top |
|
|
John E. Malmberg
*nix forums Guru Wannabe
Joined: 30 May 2005
Posts: 264
|
| Posted: Fri May 27, 2005 4:12 pm Post subject:
Re: Quotas and disk space requirements for build/test Perl?
|
|
|
On Thu, 10 Feb 2005, Michael G Schwern wrote:
| Quote: | On Thu, Feb 10, 2005 at 07:27:43AM -0500, John E. Malmberg wrote:
I had to dedicate an RF72 on my VAX 4000-500 in order to do a debug
build. I can not afford to add more disks to my hobby system, as all
three DSSI bays are full, and I do not have a DSSI to SCSI converter.
Disk space can be a premium on older or hobby systems.
I have run out of disk space on two systems that I have attempted to do
debug builds.
Obviously I am missing something. Can't you pick up a used 10 gig IDE disk
for $20 these days?
|
The adapters to connect it to a VAX that does not have built in SCSI will
cost at least $300 to $1000 for the Q-BUS to SCSI (used and apparently
still in high demand) + the IDE to SCSI converter which was a few hundred
$ the last time I checked with no one yet admitting to have gotten that
unspported configuration to work.
Some of the IDE to SCSI converters are known not to work with OpenVMS
because they have not implmented the SCSI features that OpenVMS uses.
A Russian posted the schematics for their Q-BUS to IDE adapter on the
Internet a few years back. The drivers are only for 4.x of VAX/VMS.
Only some of the later generation of Alpha systems can take IDE drives,
and then they are limited to 137 GB.
| Quote: | Just how big are these debug builds?
|
The one that I just got completed is showing to be 1.37 GB in size. Out
of a 4 GB disk.
I notice that there is some mention in the documenation of Perl that
indicates that it is currently about 80 MB of source.
| Quote: | Or are we talking some really old hardware here?
|
Old OpenVMS systems seem to stick around for ever. :-)
-John
wb8tyw@qsl.net
Personal Opinion Only |
|
| Back to top |
|
|
PPrymmer@factset.com
*nix forums beginner
Joined: 08 Jul 2005
Posts: 21
|
| Posted: Fri May 27, 2005 4:12 pm Post subject:
Re: Changing osname or ^O from VMS.C at startup?
|
|
|
"John E. Malmberg" <malmberg@Encompasserve.org> wrote on 02/15/2005
03:21:01 PM:
| Quote: | If anyone has any suggestions on an easy way to do this, please let me
know.
|
I'd recommend rewriting config.h before you compile perl under GNV, later
you could modify the Configure script itself to recognize GNV as a
distinct osname. Here for example is how perl 5.8.1 is built to recognize
VMS:
$ search PERL_ROOT:[LIB.VMS_AXP.5_8_1.CORE]config.h osname
/* OSNAME:
#define OSNAME "VMS" /**/
Of course changing that and recompiling does not give you the flexibility
of
a symbol or logical that you requested. However there is precedent for
such
a distinct setting of $^O. Namely the Windows native port calls itself
'MSWin32' whereas the cygwin (GNU/bash et al) environment calls
itself 'cygwin' in perl's $^O variable.
Peter Prymmer |
|
| Back to top |
|
|
John E. Malmberg
*nix forums Guru Wannabe
Joined: 30 May 2005
Posts: 264
|
| Posted: Fri May 27, 2005 4:12 pm Post subject:
Changing osname or ^O from VMS.C at startup?
|
|
|
It appears that the VMS specific file name behavior is tied to many perl
scripts that are checking the ^O for 'VMS'.
What I would like to investigate is having a option where a symbol or
logical name could be used by the init and pre-init code in VMS.C
to change the ^O to report 'GNV'. That same feature would also cause
the DECC feature settings to go to full UNIX/POSIX filename compatibility
mode.
In investigating why the first standard test for symlinks on perl was
failing, it turns out that the fast_abs_path() and abs_path() call VMS
specific code including using rms calls to return the path. This
existing code does not know how to follow a symbolic link to the
real path, and since other code calls those same routines that should
not return a real path, but the link value, a new routine would be needed
for the abs_path routines to use.
Alternatively, symbolic links virtually require UNIX/POSIX path names to
function, which means that they are most likely only to be used in a
full POSIX environment.
It looks like when Perl does not recognize the value of ^O, it defaults
to POSIX/UNIX behavior on file handling.
I have not found out yet how to read or change the value of ^O from C, as
it seems to only be set by config.pm, and I am not sure if config.pm is
used after Perl is built.
If anyone has any suggestions on an easy way to do this, please let me
know.
Thanks,
-John
wb8tyw@qsl.net
Personal Opinion Only |
|
| Back to top |
|
|
John E. Malmberg
*nix forums Guru Wannabe
Joined: 30 May 2005
Posts: 264
|
| Posted: Fri May 27, 2005 4:12 pm Post subject:
mm_vms.pm question.
|
|
|
In MM_VMS.PM, there is a comment that unixify will sometimes return a
string with an off-by-one trailing null.
And what does that mean? More than one null terminator?
Do you have a reproducer for that problem?
Thanks,
-John
wb8tyw@qsl.net
Personal Opinion Only |
|
| Back to top |
|
|
Craig A. Berry
*nix forums Guru Wannabe
Joined: 27 May 2005
Posts: 143
|
| Posted: Fri May 27, 2005 4:12 pm Post subject:
Re: Building release 5.8.4 on HP I64
|
|
|
It looks to me like you're experiencing a configuration problem such
that it's not recognizing that you have built-in socket support in
the CRTL. Go to your top-level directory and search the generated
configuration for socksizetype and ccname like so:
$ search config.sh socksizetype,ccname
ccname='DEC'
socksizetype='unsigned int'
At 7:58 AM -0600 5/27/05, Doug Woronuk wrote:
| Quote: | I downloaded Craig Barry's PERLBUILD584.ZIP file onto an HP Itanium at OpenVMS release 8.2 and am now trying to build Perl with ithread support.
I've never had the, um, "pleasure" of building Perl before and was quite hopeful that if I followed the commands that were described in the readme file, that it would just work. I contacted Craig to find out what had to be done to build with thread support, and adjusted the "@configure" command accordingly. A handful of C files compiled fine, then it failed on PP_SYS.C as shown:
CC /Include=[]/Standard=Relaxed_ANSI/Prefix=All/Obj=.obj/NoList/float=ieee/ieee=
denorm_results/Define=PERL_CORE PP_SYS.C
Sock_size_t bufsize;
....^
%CC-E-BADPARSEDECL, In this declaration, "undef" must specify a type.
at line number 1544 in file PERLKIT:[SOURCE]PP_SYS.C;1
bufsize = SvCUR(bufsv);
....^
%CC-E-UNDECLARED, In this statement, "bufsize" is not declared.
at line number 1662 in file PERLKIT:[SOURCE]PP_SYS.C;1
while ((childpid = wait4pid(-1, &argflags, 0)) == -1 &&
...............^
%CC-I-QUESTCOMPARE1, In this statement, the unsigned expression "(childpid=Perl_
wait4pid(...))" is being compared with an equality operator to a constant whose
value is negative. This might not be what you intended.
at line number 4022 in file PERLKIT:[SOURCE]PP_SYS.C;1
while ((result = wait4pid(pid, &argflags, optype)) == -1 &&
...............^
%CC-I-QUESTCOMPARE1, In this statement, the unsigned expression "(result=Perl_wa
it4pid(...))" is being compared with an equality operator to a constant whose va
lue is negative. This might not be what you intended.
at line number 4054 in file PERLKIT:[SOURCE]PP_SYS.C;1
I'm not a C programmer, but I was able to conclude that PP_SYS.C includes "perl.h", which includes either "uconfig.h" or "config.h" depending on the PERL_MICRO ifdef test. "uconfig.h" defines "Sock_size_t" as an "int", while "config.h" defines "Sock_size_t" as "undef", so presumably it is "config.h" that is being included.
I'm not sure how to solve this. I see that uconfig.h and config.h are build by the configuration process. Is there something that I should have done differently during the configuration?
Thanks for any help you can provide.
Doug Woronuk
Senior Software Analyst
Communications Protocols
MegaSys Computer Technologies
mailto:Doug.Woronuk@megasys.com>Doug.Woronuk@megasys.com
403.295.0511
This e-mail message and any attachments are confidential and may be
privileged. If you are not the intended recipient, please notify MegaSys
immediately -- by replying to this message or by contacting MegaSys -- and
destroy all copies of this message and any attachments. Thank you.
|
--
________________________________________
Craig A. Berry
mailto:craigberry@mac.com
"... getting out of a sonnet is much more
difficult than getting in."
Brad Leithauser |
|
| Back to top |
|
|
Google
|
|
| Back to top |
|
|
|
|
The time now is Tue Dec 02, 2008 5:42 am | All times are GMT
|
|
Bad Credit Mortgages | Credit Card | Loans | Free Online RPG | Adverse Credit Remortgage
|
|
Copyright © 2004-2005 DeniX Solutions SRL
|
|
|
|
Other DeniX Solutions sites:
Unix/Linux blog |
electronics forum |
medicine forum |
science forum |
|
|
Privacy Policy
|
Powered by phpBB © 2001, 2005 phpBB Group
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
Forum index
»
Not Unix
»
VMS
»
vmsperl
