When I enable hard links on VMS, it exposed that the t/io/fs.t is not
testing what the comments indicate that it is testing.
The correct test would be to see if the $mode of the third link matched
the $mode for the original file.
What the test is actually doing is testing to see if the umask
In sub makefile in module MM_UNIX.PM, the command false is being added
to the DESCRIP.MMS as part of the MAKE_FRAG text block.
As there is no false command on VMS, this is causing rerunning a make
to fail.
Would adding the following line before the return $m be the fix for
this? Or is
Two config parameters were added to Configure so they also need to be
added to configure.com. VMS does not have those functions.
-John
[EMAIL PROTECTED]
Personal Opinion Only
--- configure.com_25452 Sat Sep 17 21:48:07 2005
+++ configure.com Sun Sep 18 03:22:46 2005
@@ -5580,6 +5580,8 @@
I am looking for comments on a couple of VMS specific behavior issues.
Unless there are some objections, I would like to make these changes:
1. Fix usage of HOME and a few other environment variables used inside
of the Perl binary.
Perl is assuming that the HOME and possibly some other
Michael G Schwern wrote:
Maint is still using MakeMaker 6.17 which is now TWO YEARS OLD!
Last I checked there was some VMS failure or another possibly tied to
File::Find but I don't have details. I really rather 5.8.8 not go out with
6.17 again, 6.30 is good and stable. Can we just take the
Rafael Garcia-Suarez wrote:
On 9/19/05, John E. Malmberg [EMAIL PROTECTED] wrote:
When I enable hard links on VMS, it exposed that the t/io/fs.t is not
testing what the comments indicate that it is testing.
The correct test would be to see if the $mode of the third link matched
the $mode
This patch adds the ability to build Perl on 64 bit VMS V8.2 with
support for hard links, and the newer CRTL features.
Changes to configure.com:
1. Protect the link operations for the tests from someone aliasing the
link command to default for a /DEBUG build.
2. Allow override of the make
Peter Prymmer wrote:
Michael G Schwern [EMAIL PROTECTED] wrote on 09/19/2005 08:15:51 PM:
On Sun, Sep 18, 2005 at 11:52:20PM -0400, John E. Malmberg wrote:
As there is no false command on VMS, this is causing rerunning a make
to fail.
I see a number of uses of false in MM_Unix. Rather
Michael G Schwern wrote:
On Tue, Sep 20, 2005 at 08:09:56AM -0400, John E. Malmberg wrote:
A VMS exit 44 will also cause MMS/MMK by default to abort the makefile
with MMS/MMK also exiting with an error.
I believe this is the desired behavior.
I think I should test that out tonight
Michael G Schwern wrote:
On Tue, Sep 20, 2005 at 02:02:24PM -0400, Peter Prymmer wrote:
By the way, why is `false` desirable to have in a Makefile?
Why does MakeMaker need to know how to do it?
It appears it wants to make sure certain targets fail when the commands
themselves don't
Michael G Schwern wrote:
On Tue, Sep 20, 2005 at 02:02:31PM -0700, Michael G Schwern wrote:
One is in MM_Unix-perldepend which appears to be unused.
I lied, its not unused. Its used when building perl and XS modules so that's
probably important. But it only happens when config.h is out
Jeremy Begg wrote:
Hello John,
This patch adds the ability to build Perl on 64 bit VMS V8.2 with
support for hard links, and the newer CRTL features.
For which version(s) of Perl is this suitable? 5.8.7 is the latest stable
release; can the patch be used with that?
I have not run that
Nicholas Clark wrote:
On Mon, Sep 19, 2005 at 05:56:50PM -0700, Michael G Schwern wrote:
Maint is still using MakeMaker 6.17 which is now TWO YEARS OLD!
Last I checked there was some VMS failure or another possibly tied to
File::Find but I don't have details. I really rather 5.8.8 not go out
VMS has a number of features that vary with the version of VMS, and also
features that can be enabled.
Perl scripts running on VMS may need to know what features are enabled,
or to enable the features.
It appears to me that the vmsish module is the place to put these if I
can figure out how
Two other features are also needed:
vmsish::vms_pipe_mbx_line_size($value)
Currently this is controlled by an undocumented logical name.
vmsish::unlink_all_versions($value)
This needs to be a run time instead of a build time setting. Also the
rename method needs to honor it.
-John
[EMAIL
Craig A. Berry wrote:
At 6:57 AM -0400 9/22/05, John E. Malmberg wrote:
Two other features are also needed:
vmsish::vms_pipe_mbx_line_size($value)
Currently this is controlled by an undocumented logical name.
It is documented. See
http://perldoc.perl.org/perlvms.html#Pipes
That's
Peter Prymmer wrote:
: Much (not all) of this information sounds like it might do better
: to reside in a non pragmatic module with a name like VMS::Config
: or VMS::FeatureSet; rather than the pragmatic module intended to
: alter run time behavior of a script and its loaded modules.
It also
Michael G Schwern wrote:
On Sat, Aug 13, 2005 at 10:33:45PM -0400, John E. Malmberg wrote:
Test 7 is failing because normally on VMS, unless you specify otherwise,
you get exclusive access to the file, so the second open is failing.
The logical name DECC$FILE_SHARING defined as ENABLE
Michael G Schwern wrote:
On Sun, Sep 25, 2005 at 12:28:38AM -0400, John E. Malmberg wrote:
So it appears the problem is that nothing is calling fsync(), but I am
not sure what needs to be changed to fix this. I also do not know if
this affects anything other than VMS.
Since your the only
Peter Prymmer wrote:
John E. Malmberg [EMAIL PROTECTED] wrote on 09/22/2005 05:15:17 PM:
Peter Prymmer wrote:
: Much (not all) of this information sounds like it might do better
: to reside in a non pragmatic module with a name like VMS::Config
: or VMS::FeatureSet; rather than the pragmatic
Well, I thought that it would be simpler than it has turned out to be,
and obviously I am missing a concept or two somewhere.
On VMS, the methods in Filespec.pm are actually implemented in vms.c not
in the .pm module.
I thought that I could add some stub methods it and put them in the
Michael G Schwern wrote:
On Mon, Sep 26, 2005 at 11:01:42PM -0400, John E. Malmberg wrote:
Well, I thought that it would be simpler than it has turned out to be,
and obviously I am missing a concept or two somewhere.
Filespec.pm uses AutoLoader, mostly to prevent the Perl versions from
ever
CPAN is showing Nicholas Clark as the maintainer of VMS::Filespec, and
the comments are showing Charles Baily as the maintainer.
This adds the methods needed for other Core modules to properly
interpret VMS file specifications.
Also included is an update to the documentation for the existing
Carl Friedberg wrote:
Hi Peter and John,
I have not had a look at the logicals piece in quite a
while. I ran into a design issue, because I felt that
the interface needed to be changed, and I got stuck
worrying about how to make the change so it wouldn't
break earlier users...
Unfortunately, I
John E. Malmberg wrote:
Michael G Schwern wrote:
On Wed, Sep 28, 2005 at 12:55:47AM -0400, John E. Malmberg wrote:
From my tests on Perl 5.8.7, the modules that need to be changed to test
for the existence of these new methods and if they are defined to act
on the results are:
Just
Michael G Schwern wrote:
On Wed, Sep 28, 2005 at 12:36:40PM -0400, John E. Malmberg wrote:
So then the VMS related choices for the lib/test/simple/t/create.t would be:
A. Re-write it to avoid the VMS specific issue, like the patch that you
posted earlier does.
Ahh, except it wasn't a VMS
Michael G Schwern wrote:
On Wed, Sep 28, 2005 at 04:44:15PM -0400, John E. Malmberg wrote:
So I guess what I'm saying here is I'm happy to code to the lowest common
denominator, or there is no intersection to do things like if this
system has feature X, do Y. What I do not want
Michael G Schwern wrote:
Put the logic in a module. Put the module on CPAN.
And this part is really my fault. I've been meaning to write
File::System::Spec and Operating::System::Spec for a long time
now to allow easy answers to just these sorts of questions.
Would this fit the bill? It
Yuval Kogman wrote:
On Fri, Sep 30, 2005 at 00:56:09 -0400, John E. Malmberg wrote:
The logic is problematic...
On OSX, for example, I could mount an HFS file system that is case
sensitive or not, interact with SMB on windows which is not, SMB on
samba which i suspect is, FAT-xx and NTFS
Michael G Schwern wrote:
On Fri, Sep 30, 2005 at 12:25:04PM -0400, John E. Malmberg wrote:
The current interface is good enough for the default filesystem, I
guess, but you should be able to ask about a specific file system,
e.g.:
my $x = File::System::Spec-new(File::Spec-catfile
Sebb wrote:
On 03/10/05, John E. Malmberg [EMAIL PROTECTED] wrote:
Sebb wrote:
On 03/10/05, John E. Malmberg [EMAIL PROTECTED] wrote:
New files opened for write are created in the first directory of a
search list. New files opened for append are created in the last
directory of a search
Sebb wrote:
If you try the same experiment from DCL you will get a different result.
How are you doing it using DCL?
I am pretty sure that I used to do it with $open/append. It appears
since I put a reproducer on comp.os.vms several years ago that the
behavior has been changed. Now I
Steven Schubiger wrote:
On Tue, Oct 04, 2005 at 07:13:01PM -0500, Steve Peters wrote:
The statement
Not tested on VMS or MacOS, although there is platform specific code
for those. does scare me a bit though.
The same occured to me, although it doesn't necessarily imply that it doesn't
Peter Prymmer wrote:
So this patch should not do harm. The .FIRST directive
has me a little bit worried about MMS (I have only test
with MadGoat Make Utility V3.9-6).
MMS also has a .FIRST directive.
Until MMS is fixed to handle case preserved ODS-5, I can not test with it.
Note that -
Craig A. Berry wrote:
At 7:38 AM -0400 10/6/05, John E. Malmberg wrote:
On VMS, it is possible logical names that are not in the EXEC or
higher privileged mode should be considered tainted, and ones that in
the EXEC mode or higher should not be, if I understand what tainting is
supposed
Nicholas Clark wrote:
X-UID: 266
I'm trying to build blead on VMS testdrive. It seems to be going wrong here:
Making B (dynamic)
%MMS-W-GMFUTURE, Time for [--.LIB].EXISTS is in the future: 8-OCT-2005 13:46:42
.00
Am I doing something daft here? Or is that machine confused as to what
Nicholas Clark wrote:
I'm trying to hammer out the problems with maint on VMS using testdrive.
I've hit a problem that i can't solve:
$ mms pp_sys.obj
$mms/macro=__DEBUG__=1 pp_sys.obj
CC/DECC/NOANSI_ALIAS /Include=[]/Standard=Relaxed_ANSI/Prefix=All/Obj=.obj/NoLis
Nicholas Clark wrote:
On Mon, Oct 10, 2005 at 07:59:48PM -0500, Craig A. Berry wrote:
I've tried on user1 and user5 on spe180, and I'm still getting the
same errors. I don't know how to do this from the native VMS shell,
but the bash version of things looks wrong:
bash$ date
Tue Oct 11
H.Merijn Brand wrote:
Can you check/update this patch regarding VMS please?
Change 25733 by [EMAIL PROTECTED] on 2005/10/10 13:47:17
Add probe for unsetenv ()
Subject: Re: Perl's handling of environ breaks on Solaris 10
From: Steve Peters [EMAIL PROTECTED]
Date:
H.Merijn Brand wrote:
Can you check/update this patch regarding VMS please?
Change 25733 by [EMAIL PROTECTED] on 2005/10/10 13:47:17
Add probe for unsetenv ()
Subject: Re: Perl's handling of environ breaks on Solaris 10
From: Steve Peters [EMAIL PROTECTED]
Date:
RE: change #25688
John E. Malmberg wrote:
H.Merijn Brand wrote:
On 04 Oct 2005 02:18:27 -0700, Gisle Aas [EMAIL PROTECTED] wrote:
This patch expand on Ken's by getting rid of STATUS_NATIVE_SET() for
the non-VMS branch and renames STATUS_NATIVE_EXPORT as STATUS_EXIT
since the value is only
I think I have the exit code stuff figured out, and I am trying to
figure out how to add the option required by GNV to return the UNIX exit
codes embedded in a VMS status.
The vmsish pragma does not make sense to enable this feature, as it is
really a case of being compatible with GNV and
Change 25514 added a test that makes a list assignment to %ENV.
According to comments in mg.c, this will not work on VMS, EPOC, and SYMBIAN.
This patch only fixes the VMS case to skip that test as it is the only
one I can test.
-John
[EMAIL PROTECTED]
Personal Opinion Only
---
Yitzchak Scott-Thoennes wrote:
On Fri, Oct 14, 2005 at 02:44:55PM +0200, H.Merijn Brand wrote:
On Fri, 14 Oct 2005 00:33:29 -0700, Yitzchak Scott-Thoennes
[EMAIL PROTECTED] wrote:
A change to patchlevel.h broke this; later on Configure compares
what's in .patch to $perl_patchlevel and gets:
twice in ways that break VMS in just the last few months.
At 1:49 AM -0400 10/14/05, John E. Malmberg wrote:
+ * vaxc$errno is only suppose to be valid if errno == EVMSERR, otherwise
+ * it's contents can not be trusted.
That's what the CRTL does, not what Perl does. There are many, many
First sets of updates to perlport.pod.
More will be needed later. I think that many of the features that are
said not to be implemented on VMS are already there if the correct DECC$
feature logicals are set and you are using ODS-5 file systems.
-John
[EMAIL PROTECTED]
Personal Opinion Only
Reworked, retested, and resubmitted.
In perl.c:
In the routine Perl_my_exit, use the new macro STATUS_UNIX_EXIT_SET to
set the native and UNIX exit codes correctly.
In perl.h:
Fix STATUS_... macros to handle both the encoded POSIX exit codes and
traditional documented VMS EXIT code
With 64 bit OpenVMS 7.2, The OpenVMS ODS-5 file system can support paths
as long as 4096 characters long.
Perl on VMS is currently limited in most places to paths that are only
255 characters long.
I am looking at removing that restriction on 64 bit OpenVMS.
The issue that comes up is that
Since building with VAXC is no longer supported, nothing should be
defining vax11c. The current compilers for VMS do not define this macro.
These are the only two locations it still is in the source.
Any objections if the references to vax11c eventually get removed?
Is there any possibility
John E. Malmberg wrote:
Left out in my previous description.
In Perl.h:
Removed test for vax11c being defined. If it is defined, you are very
far away from getting the behavior that STANDARD_C implies for the compiler.
It is possible that the compile may have appear to have succeeded
Have the problems that you are seeing on the testdrive systems with the
time been resolved yet?
Also I assume that people are aware of the hobby VMS program where free
licenses are available for home personal non-profit use, and that Open
Source VAX emulators are available for most platforms
The following is a summary of known issues of blead on VMS.
t/io/crlf_through.FAILED--unexpected output at
test 0
Can't find string terminator ) anywhere before EOF at -e line 1.
T/IO/CRLF_THROUGHFAILED--unexpected output at test 0
TODO list (not in the order that I may get to them, and if someone gets
to them first, I certainly do not mind :-).
* VMS::Filespec::case_tolerant now reflects the true state of
case tolerance expected by the person running Perl.
Unfortunately several files and directories in Perl are being
Craig A. Berry wrote:
Change 25824 by [EMAIL PROTECTED] on 2005/10/22 16:43:40
VMS threaded build fixes for things broken in #25783
- if (eqv *eqv) Perl_my_chdir(eqv);
+ if (eqv *eqv) my_chdir(eqv);
So I do not break things again, can you explain to me what the
John E. Malmberg wrote:
The following is a summary of known issues of blead on VMS.
t/pod/pod2usage2..FAILED at test 2
not ok 2 - Exit status pod2usage ()
T/POD/POD2USAGE2FAILED at test 2
This test appears new to VMS. Need to investigate.
This test is failing
Craig A. Berry wrote:
At 2:19 PM -0400 10/22/05, John E. Malmberg wrote:
my_chdir is a macro that will have an extra argument for interpreter
context in the case of building with threads enabled, but will be
identical to Perl_my_chdir for a non-threaded build. Here's what the
macro expansion
Craig A. Berry wrote:
At 1:40 PM -0400 10/22/05, John E. Malmberg wrote:
TODO list (not in the order that I may get to them, and if someone
gets to them first, I certainly do not mind :-).
* VMS::Filespec::case_tolerant now reflects the true state of
case tolerance expected by the person
Craig A. Berry wrote:
At 4:19 PM -0400 10/22/05, John E. Malmberg wrote:
My guess, though I've never pinned it down and watched it happen in
the debugger, is that when we see spurious newlines, it's because a
flush has taken place or the buffer has filled up. There is lots and
lots
[EMAIL PROTECTED] wrote:
If you have a way to determine at
start-up that you're running under bash, you could hard-wire this or
at least change the default in that environment. See the following
docs on how this works:
I currently use the following to detect bash. While it is probably
In the pipe creation code, the st_ino check is against the uninitialized
copy instead of the real ino_t.
-John
[EMAIL PROTECTED]
Personal Opinion Only.
--- /rsync_root/perl/vms/vms.c Sat Oct 22 13:11:49 2005
+++ vms/vms.c Sat Oct 22 20:12:06 2005
@@ -3123,9 +3123,9 @@
fstat(fileno(fp),
I think I have most of this untangled, except somewhere I am missing a
critical step which is showing up in two tests.
The attached patches get me to this point, which is close, but obviously
not good enough.
It appears in these two tests, the exit handling is working in the
expected UNIX
John E. Malmberg wrote:
Which the code that is failing is:
$exit_arg = 42;
$exit = run(END { \$? = $exit_arg });
$exit_arg = (44 7) if $^O eq 'VMS';
is( $exit 8, $exit_arg, 'Changing $? in END block' );
The severity for 42 is ERROR and apparently on VMS, changing the
status
I think I have found it.
The old default behavior is in effect when the VMS specific macro
MY_POSIX_EXIT evaluates to 0.
When setting $? in mg.c, as a side effect, if $? is not 0, then default
VMS behavior is to set STATUS_NATIVE to SS$_ABORT.
When Perl_my_exit() is called with other than
On VMS, sprintf returns the length of the buffer.
-John
[EMAIL PROTECTED]
Personal Opinion Only
--- /rsync_root/perl/configure.com Mon Oct 24 16:33:41 2005
+++ configure.com Mon Oct 24 21:09:48 2005
@@ -5906,7 +5906,7 @@
$ WC d_socklen_t=' + d_socklen_t + '
$ WC d_sockpair=' +
Charles Lane wrote:
On Sat, 2005-10-22 at 17:02, Craig A. Berry wrote:
At 4:19 PM -0400 10/22/05, John E. Malmberg wrote:
Mailbox size limitations are the culprit; you'd think oh, just make the
mailboxes really huge, but that runs into the limits of normal user
accounts. Having Perl run
In vms/perlvms.pod :
Document traditional VMS behavior of Cdie, and also document the
latent POSIX_EXIT behavior changes for Cdie and C$?.
In perl.c:
Fixes to generate both the traditional and latent POSIX_EXIT VMS
behaviors and provide comments about why they are so different from
Rafael Garcia-Suarez wrote:
John E. Malmberg wrote:
In vms/perlvms.pod :
Document traditional VMS behavior of Cdie, and also document the
latent POSIX_EXIT behavior changes for Cdie and C$?.
Thanks, applied as #25849 (with change #25839 backed out).
Your doc changes are a bit difficult
In vms.c:
For platforms/versions that support it, a new do_mp_rmsexpand() that can
support longer filenames.
Fix memory leaks in old do_mp_rmsexpand() when it gets an apparent UNIX
format path that it can not translate.
Replace memcpy() with memmove() if there is a possibility of an
BG - Ben Armstrong wrote:
I'm interested in the work John and others are doing on VMSish issues,
particularly the recent work on pipes, because I will likely need this
for the VMS port of Ruby I seem to have inherited when the former
maintainer dropped off the scene. Is any portion of this
The File::Basename::dirname('foo') is returning the current working
directory instead of File::Spec-cur_dir as would be the behavior on
other platforms.
Is this something that can be changed with out breaking other things?
The current behavior silently breaks a UNIX based perl script that is
Abe Timmerman wrote:
Hi,
I get this warning on VMS:
# define do_exec(cmd) do_exec3(cmd,0,0)
..^
%CC-W-MACROREDEF, The redefinition of the macro do_exec conflicts with a
current definition because the number of parameters is different. The
redefinition is
Abe Timmerman wrote:
This patch seems a logical follow up for 25969 on VMS (cando stuff)
Also needed is the attached vmsish.h patch.
-John
[EMAIL PROTECTED]
Personal Opinion Only
diff -ruN perl-blead/vms/vms.c perl-current/vms/vms.c
--- perl-blead/vms/vms.cWed Oct 26 15:54:10 2005
A rule needs to be added so that $(CORECFLAGS) is used for compiling
mathoms.c. Otherwise some needed macros are not defined.
Todo:
1. Should building mathoms.c be a configure option on VMS?
Or just dropped.
2. The definition of do_exec() macro needs to be determined.
Currently there
Peter Prymmer wrote:
This bug:
$ perl -e print defined(VMS::Filespec::vmspath('perlshr'))
$ perl -e print defined(VMS::Filespec::vmspath('perlshr_not_logical'))
1
Is causing trouble for sub init_main in ExtUtils::MakeMaker::MM_Unix.pm
which calls catfdir() to turn a NAME into a FULLEXT macro.
t/op/array.t is failing on OpenVMS because it is calling reset 'b',
and perl can not reset %ENV hash values on VMS.
-John
[EMAIL PROTECTED]
Personal Opinion Only
--- /rsync_root/perl/t/op/array.t Wed Oct 19 17:18:03 2005
+++ t/op/array.tMon Nov 21 20:45:47 2005
@@ -61,7 +61,7 @@
t/op/pat.t is failing on OpenVMS because it is calling reset 'X', and
perl can not reset %ENV hash values on VMS.
That reset 'X' or other letters will generate a warning on OpenVMS would
seem to make this routine not useful on it.
-John
[EMAIL PROTECTED]
Personal Opinion Only
---
The file ext/List/Util/t/p_tainted.t is assuming a UNIX format pathname
is returned by __FILE__.
This is a quick fix for VMS.
A proper fix needs use the routines to either generate a relative
pathname or concatenate paths.
Also I need to find out is where __FILE__ is being set because I
Rafael Garcia-Suarez wrote:
On 11/22/05, John E. Malmberg [EMAIL PROTECTED] wrote:
The file ext/List/Util/t/p_tainted.t is assuming a UNIX format pathname
is returned by __FILE__.
__FILE__ is initially set from PL_origfilename in perl.c. It's saved
as CopFILE in each cop (control op
I can not find where the file bar.tar is being created in this test.
The test is failing on VMS because it does not exist at the read phase.
ok 14 - Object created - read
ok 15 - The object isa Archive::Tar
# type = [.src.short]bar.tar
# state = uncompressed
Could not create filehandle for
Rafael Garcia-Suarez wrote:
On 11/29/05, John E. Malmberg [EMAIL PROTECTED] wrote:
I can not find where the file bar.tar is being created in this test.
Actually it's created by 00_setup.t. As tests are supposed to be
executed in asciibetical order, this should be fine. Is 00_setup.t
failing
Carl Friedberg wrote:
Hi,
This is probably a FAQ, but I am trying to
resurrect the VMS SMG module.
Please look at the Readline support in Perl and the Perl debugger after
you get it resurrected.
If you can get Perl to use SMG for the readline support, it looks like a
trivial change to
In abs2rel() fix handling of directory trees so that the test $file =
File::Spec::VMS-abs2rel('[t1.t2.t3]file', '[t1.t2.t3]') returns 'file'
instead of an empty string.
In canonpath(), fix case where '[]' was totally optimized away instead
of just returning '[]'.
$file =
Cwd.pm will need an update for OpenVMS past version 8.2, for supporting
symbolic links and the UNIX emulation modes.
Using the realpath routine in Cwd.pm has a very significant performance
penalty as compared to using the realpath() routine that will be
provided by OpenVMS.
OpenVMS can
Ken Williams wrote:
Hi John,
Thanks for the patch, I've applied it. Could I trouble you to also add
a few tests to Spec.t to exercise these dead bugs?
Someone already did with a recent change to Spec.t, which made them show
up as failed at the same time I made a significant change to
Ken Williams wrote:
On Dec 6, 2005, at 11:46 AM, John E. Malmberg wrote:
Ken Williams wrote:
I was thinking we could add those as TODO tests, but I was unaware of
the problems with VAX legacy stuff.
There are some bugs that are in the legacy stuff that I am concerned if
I change
Is there any real reason that commands are being truncated if they have
an embedded new line?
Removing these lines makes test t/op/gv.t work on OpenVMS and improves
some other tests that are still failing for other reasons.
The way that parameters are passed to sub-processes on OpenVMS will
Craig A. Berry wrote:
Since applying this patch, Perl builds up to the point where it tries
to run the Makefile.PL for the first extension, at which point it
rapidly consumes all available stack space (after apparently writing
a complete descrip.mms). This is with a thread-enabled build.
Craig A. Berry wrote:
At 4:46 PM -0500 12/13/05, John E. Malmberg wrote:
Obviously we are so far not having the desired effect of reducing
stack space usage.
Obviously I have an error somewhere.
I do see one example of allocating a long filename on the stack:
$ SEARCH/EXACT vms.c tmp
embed.h is ending up with a bad definition of unlnk() when
UNLINK_ALL_VERSIONS is defined which is causing a compile error on VMS
when a threaded perl is being built.
It is not happening when non-threaded perls are being built.
-John
[EMAIL PROTECTED]
Personal Opinion Only
Craig A. Berry wrote:
$ @configure -Dusedevel -Dusevmsdebug -Duseithreads -des
Ok, I will try again.
I just completed a build with:
$ @configure -Duselargefiles -Dcf_email=SYSTEM -Dusevmsdebug
-Dusethreads -de
No problems with the build once I removed the -Dunlink_all_versions
-John
John E. Malmberg wrote:
I just completed a build with:
$ @configure -Duselargefiles -Dcf_email=SYSTEM -Dusevmsdebug
-Dusethreads -de
No problems with the build once I removed the -Dunlink_all_versions
Correction, doing the MMK REALCLEAN is resulting in miniperl generating
all sorts
The bug seems to be in *mp_do_fileify_dirspec.
else { /* This is a top-level dir. Add the MFD to the path. */
if (buf) retspec = buf;
else if (ts) Newx(retspec,retlen+16,char);
else retspec = __fileify_retbuf;
cp1 = esa;
cp2 = retspec;
Craig A. Berry wrote:
At 11:21 PM -0500 12/14/05, John E. Malmberg wrote:
The bug seems to be in *mp_do_fileify_dirspec.
while (*cp1 != ':') *(cp2++) = *(cp1++);
With this value of esa, the while statement just runs away, and
will eventually cause *cp2 to write over something unless
John E. Malmberg wrote:
Craig A. Berry wrote:
At 11:21 PM -0500 12/14/05, John E. Malmberg wrote:
The bug seems to be in *mp_do_fileify_dirspec.
while (*cp1 != ':') *(cp2++) = *(cp1++);
With this value of esa, the while statement just runs away, and
will eventually cause *cp2
I am testing a fix for this problem, and I am seeing a hang on the test
[.t.op]threads.t
Is this a known problem?
1..4
ok 1 - fresh_perl - delete() under threads
ok 2 - fresh_perl - weaken ref under threads
ok 3 - fresh_perl - weaken ref \#2 under threads
# parent 471639: continue
# parent
This buffer overrun bug in vms.c/mp_do_fileify_dirspec has been there
for a while and was made more visible by the recent changes to allow
support of longer file names.
This patch should also be applied to the maint and upcoming 5.8 streams.
-John
[EMAIL PROTECTED]
Personal Opinion Only
---
I needed to add this const qualifier for utf8.c to compile.
-John
[EMAIL PROTECTED]
Personal Opinion Only
--- /rsync_root/perl/utf8.c Sun Jan 1 05:45:21 2006
+++ ./utf8.cSun Jan 1 21:41:43 2006
@@ -2236,7 +2236,7 @@
register const U8 *p1 = (const U8*)s1;
register const U8
Steve Peters wrote:
Change 26632 by [EMAIL PROTECTED] on 2006/01/04 03:43:20
Added snprintf() and vsnprintf() to configure.com as 'undef'.
TODO, these routines are present on OpenVMS 7.3-2 and later.
http://h71000.www7.hp.com/doc/82FINAL/5763/5763pro_072.html
-John
[EMAIL PROTECTED]
Craig A. Berry wrote:
Actually, we explicitly turn it off in configure.com:
I only looked in the descrip_mms.template so I missed that.
-John
[EMAIL PROTECTED]
Personal Opinion Only
Craig A. Berry wrote:
At 10:23 PM -0500 1/6/06, John E. Malmberg wrote:
[-.lib.ExtUtils.t]Manifest.t44 1024492 4.08% 26 29
[-.lib.ExtUtils.t]PL_FILES.t44 1024 95 55.56% 3-7
I think that these are failing because of the issue addressed by
the patch
201 - 300 of 663 matches
Mail list logo
