Mailing List Archive: Perl: porters

[perl #78132] [PATCH] Fix perl build problems on Stratus VOS

Index | Next | Previous | View Threaded

perlbug-followup at perl

Sep 29, 2010, 8:05 AM

Post #1 of 17 (576 views)
Permalink

[perl #78132] [PATCH] Fix perl build problems on Stratus VOS

# New Ticket Created by Paul Green
# Please include the string: [perl #78132]
# in the subject line of all future correspondence about this issue.
# <URL: http://rt.perl.org/rt3/Ticket/Display.html?id=78132 >

--- perl-current/Makefile.SH~ 2010-09-05 10:39:10.000000000 -0400
+++ perl-current/Makefile.SH 2010-09-14 00:49:48.000000000 -0400
@@ -555,7 +555,7 @@
.c.s:
$(CCCMDSRC) -S $*.c

-all: $(FIRSTMAKEFILE) $(MINIPERL_EXE) miniperl $(generated_pods) $(private) $(unidatafiles) $(public) $(dynamic_ext) $(nonxs_ext) extras.make
+all: $(FIRSTMAKEFILE) $(MINIPERL_EXE) $(generated_pods) $(private) $(unidatafiles) $(public) $(dynamic_ext) $(nonxs_ext) extras.make
@echo " ";
@echo " Everything is up to date. Type '$(MAKE) test' to run test suite."

--- perl-current/ext/Socket/Socket.xs~ 2010-04-24 16:58:10.000000000 -0400
+++ perl-current/ext/Socket/Socket.xs 2010-09-13 17:07:15.000000000 -0400
@@ -465,22 +465,34 @@
CODE:
#ifdef HAS_INETNTOP
STRLEN addrlen, struct_size;
+#ifdef AF_INET6
struct in6_addr addr;
char str[INET6_ADDRSTRLEN];
+#else
+ struct in_addr addr;
+ char str[INET_ADDRSTRLEN];
+#endif
char *ip_address = SvPV(ip_address_sv, addrlen);

- if(af == AF_INET) {
- struct_size = sizeof(struct in_addr);
- } else if(af == AF_INET6) {
- struct_size = sizeof(struct in6_addr);
- } else {
- croak("Bad address family for %s, got %d, should be either AF_INET or AF_INET6",
+ struct_size = sizeof(addr);
+
+ if(af != AF_INET
+#ifdef AF_INET6
+ && af != AF_INET6
+#endif
+ ) {
+ croak("Bad address family for %s, got %d, should be"
+#ifdef AF_INET6
+ " either AF_INET or AF_INET6",
+#else
+ " AF_INET",
+#endif
"Socket::inet_ntop",
af);
}

Copy( ip_address, &addr, sizeof addr, char );
- inet_ntop(af, &addr, str, INET6_ADDRSTRLEN);
+ inet_ntop(af, &addr, str, sizeof str);

ST(0) = newSVpvn_flags(str, strlen(str), SVs_TEMP);
#else
@@ -494,9 +506,23 @@
CODE:
#ifdef HAS_INETPTON
int ok;
- struct in6_addr ip_address;
- if(af != AF_INET && af != AF_INET6) {
- croak("Bad address family for %s, got %d, should be either AF_INET or AF_INET6",
+#ifdef AF_INET6
+ struct in6_addr ip_address;
+#else
+ struct in_addr ip_address;
+#endif
+
+ if(af != AF_INET
+#ifdef AF_INET6
+ && af != AF_INET6
+#endif
+ ) {
+ croak("Bad address family for %s, got %d, should be"
+#ifdef AF_INET6
+ " either AF_INET or AF_INET6",
+#else
+ " AF_INET",
+#endif
"Socket::inet_pton",
af);
}
@@ -504,8 +530,7 @@

ST(0) = sv_newmortal();
if (ok) {
- sv_setpvn( ST(0), (char *)&ip_address,
- af == AF_INET6 ? sizeof(ip_address) : sizeof(struct in_addr) );
+ sv_setpvn( ST(0), (char *)&ip_address, sizeof(ip_address) );
}
#else
ST(0) = (SV *)not_here("inet_pton");

Attachments:

perl-5.10.x.patch.txt (0.54 KB)

perl-5.12.x.patch.txt (2.74 KB)

Paul.Green at stratus

Oct 1, 2010, 1:47 PM

Post #2 of 17 (552 views)
Permalink

RE: [perl #78132] [PATCH] Fix perl build problems on Stratus VOS [In reply to]

I don't know what happened to mess up this letter. There were 3 enclosures. One of the enclosures seems to have become the body of the letter. The body of the letter got turned into an enclosure. The other two enclosures seem to be ok. Here is the original letter again. If anybody has any questions about these proposed changes, please let me know.

Gentle Perl5 Porters,

The attached text files contain patches to correct build problems on the
Stratus VOS (recently renamed "OpenVOS") operating system. I have tested
these changes on OpenVOS Release 17.0, which is the most-current
customer release. None of these changes should affect any other OS.

Makefile.SH: This patch removes the "miniperl" dependency of the "all"
target. On an operating system that does not require an executable
suffix, the miniperl$(EXE_EXT) dependency evaluates to "miniperl", too.
But on an operating system like VOS that does have an executable suffix,
miniperl$(EXE_EXT) evaluates to (in our case) "miniperl.pm" and the
"miniperl" target is unresolved. [ perl-5.10.x, perl-5.12.x,
perl-current ]

ext/Socket/Socket.xs: Sadly, OpenVOS does not yet support IPv6. I edited
the code to allow for this case, while retaining IPv6 support for
operating systems that do support it. [ perl-5.12.x, perl-current ]

The attached patches apply cleanly as of today.

These patches were prepared using "diff -u"; I have not completed the
port of git to OpenVOS, so I am unable to submit them in git format. I
apologize for this; hopefully by the time I have the next patches ready,
I'll have git working.

These patches by themselves do not get perl5 to run all of the test
cases, but they at least get it to build again.

<<perl-current.patch.txt>> <<perl-5.10.x.patch.txt>>
<<perl-5.12.x.patch.txt>>

Thanks
PG
--
Paul Green, Senior Technical Consultant, Stratus Technologies.
Voice: +1 978-461-7557; FAX: +1 978-461-3610; Mobile: +1 (978) 235-2451;
AIM: PaulGreen

perlbug-followup at perl

Oct 3, 2010, 2:22 PM

Post #3 of 17 (543 views)
Permalink

[perl #78132] [PATCH] Fix perl build problems on Stratus VOS [In reply to]

On Fri Oct 01 13:48:32 2010, paulg wrote:
> I don't know what happened to mess up this letter. There were 3
> enclosures. One of the enclosures seems to have become the body of
> the letter. The body of the letter got turned into an enclosure.
> The other two enclosures seem to be ok. Here is the original
> letter again. If anybody has any questions about these proposed
> changes, please let me know.
>
> Gentle Perl5 Porters,
>
> The
> attached text files contain patches to correct build problems on
> the
> Stratus VOS (recently renamed "OpenVOS") operating system. I
> have tested
> these changes on OpenVOS Release 17.0, which is the
> most-current
> customer release. None of these changes should affect
> any other OS.
>
> Makefile.SH: This patch removes the "miniperl"
> dependency of the "all"
> target. On an operating system that does
> not require an executable
> suffix, the miniperl$(EXE_EXT)
> dependency evaluates to "miniperl", too.
> But on an operating
> system like VOS that does have an executable suffix,
> miniperl$(EXE_EXT) evaluates to (in our case) "miniperl.pm" and the
> "miniperl" target is unresolved. [ perl-5.10.x, perl-5.12.x,
> perl-
> current ]
>
> ext/Socket/Socket.xs: Sadly, OpenVOS does not yet
> support IPv6. I edited
> the code to allow for this case, while
> retaining IPv6 support for
> operating systems that do support it. [
> perl-5.12.x, perl-current ]
>
> The attached patches apply cleanly
> as of today.
>
> These patches were prepared using "diff -u"; I have
> not completed the
> port of git to OpenVOS, so I am unable to submit
> them in git format. I
> apologize for this; hopefully by the time I
> have the next patches ready,
> I'll have git working.
>
> These
> patches by themselves do not get perl5 to run all of the test
> cases, but they at least get it to build again.
>
> <<perl-
> current.patch.txt>> <<perl-5.10.x.patch.txt>>
> <<perl-
> 5.12.x.patch.txt>>

Thank you. I’ve just applied perl-current.patch.txt as a5addb1.

I’m unsure as to the current policy with regard to maintenance patches.
Usually they are cherry-picked from blead. (I don’t know how to do that,
anyway. :-)

I’ll let someone else take over.

perlbug-followup at perl

Oct 3, 2010, 2:23 PM

Post #4 of 17 (541 views)
Permalink

[perl #78132] [PATCH] Fix perl build problems on Stratus VOS [In reply to]

On Fri Oct 01 13:48:32 2010, paulg wrote:
> The
> attached text files contain patches to correct build problems on
> the
> Stratus VOS (recently renamed "OpenVOS") operating system. I
> have tested
> these changes on OpenVOS Release 17.0, which is the
> most-current
> customer release. None of these changes should affect
> any other OS.

Is this deserving of a mention in perldelta?

rafl at debian

Oct 3, 2010, 2:26 PM

Post #5 of 17 (544 views)
Permalink

Re: [perl #78132] [PATCH] Fix perl build problems on Stratus VOS [In reply to]

"Father Chrysostomos via RT" <perlbug-followup [at] perl> writes:
> On Fri Oct 01 13:48:32 2010, paulg wrote:
>> The attached text files contain patches to correct build problems on
>> the Stratus VOS (recently renamed "OpenVOS") operating system. I have
>> tested these changes on OpenVOS Release 17.0, which is the
>> most-current customer release. None of these changes should affect
>> any other OS.
>
> Is this deserving of a mention in perldelta?

Yes, I think so. In the section for platform-specific notes.

perlbug-comment at perl

Oct 3, 2010, 4:36 PM

Post #6 of 17 (549 views)
Permalink

[perl #78132] [PATCH] Fix perl build problems on Stratus VOS [In reply to]

On Sun Oct 03 14:28:06 2010, rafl [at] debian wrote:
> "Father Chrysostomos via RT" <perlbug-followup [at] perl> writes:
> > On Fri Oct 01 13:48:32 2010, paulg wrote:
> >> The attached text files contain patches to correct build problems on
> >> the Stratus VOS (recently renamed "OpenVOS") operating system. I have
> >> tested these changes on OpenVOS Release 17.0, which is the
> >> most-current customer release. None of these changes should affect
> >> any other OS.
> >
> > Is this deserving of a mention in perldelta?
>
> Yes, I think so. In the section for platform-specific notes.

Added in 810f3b7.

jesse at fsck

Oct 3, 2010, 6:02 PM

Post #7 of 17 (540 views)
Permalink

Re: [perl #78132] [PATCH] Fix perl build problems on Stratus VOS [In reply to]

On Sun 3.Oct'10 at 14:22:19 -0700, Father Chrysostomos via RT wrote:
> I’m unsure as to the current policy with regard to maintenance patches.
> Usually they are cherry-picked from blead. (I don’t know how to do that,
> anyway. :-)

It's docced in perlpolicy.pod - this looks like a big enough chnage that
it probably doesn't qualify for backport to 5.12.

-J

>
> I’ll let someone else take over.
>
>
>

Attachments:

signature.asc (0.19 KB)

craig.a.berry at gmail

Oct 4, 2010, 6:04 AM

Post #8 of 17 (544 views)
Permalink

Re: [perl #78132] [PATCH] Fix perl build problems on Stratus VOS [In reply to]

On Sun, Oct 3, 2010 at 8:02 PM, Jesse Vincent <jesse [at] fsck> wrote:

>
> On Sun �3.Oct'10 at 14:22:19 -0700, Father Chrysostomos via RT wrote:
>> I�m unsure as to the current policy with regard to maintenance patches.
>> Usually they are cherry-picked from blead. (I don�t know how to do that,
>> anyway. :-)
>
>
> It's docced in perlpolicy.pod - this looks like a big enough chnage that
> it probably doesn't qualify for backport to 5.12.

It looked like two fairly small changes to me, both in the category of
fixing portability/build breakage and thus nominally within the
policy. Of course the pumpking's ruling is also part of the policy
and 5.14 now glimmers on the horizon, but since there was no actual
feedback on Paul's changes, I thought I'd belatedly provide some.

The one change to Socket.xs restores buildability anywhere AF_INET6 is
not defined and looks like it will leave things unchanged anywhere
that AF_INET6 is defined.

The change to Makefile.SH, while smaller, seems a bit more dangerous.
If I were to champion this change, I'd want to know why
$(MINIPERL_EXE) and miniperl both were listed as dependencies in the
all target in the first place, which should be discernible from git's
blame feature.

Paul.Green at stratus

Oct 4, 2010, 7:25 AM

Post #9 of 17 (533 views)
Permalink

RE: [perl #78132] [PATCH] Fix perl build problems on Stratus VOS [In reply to]

Craig A. Berry [mailto:craig.a.berry [at] gmail] wrote:
> On Sun, Oct 3, 2010 at 8:02 PM, Jesse Vincent <jesse [at] fsck> wrote:
> > On Sun �3.Oct'10 at 14:22:19 -0700, Father Chrysostomos via RT wrote:
> >> I'm unsure as to the current policy with regard to maintenance
> >> patches. Usually they are cherry-picked from blead.
> >> (I don't know how to do that, anyway. :-)

Feel free to ignore the files that gave the exact patch for the back-releases, but you may have to fiddle the edits a little if you back-port from blead. I submitted patches that need no fiddling.

> > It's docced in perlpolicy.pod - this looks like a big enough change
> > that it probably doesn't qualify for backport to 5.12.

I would hope they can be back-ported. They are pretty simple changes (but see below).

> It looked like two fairly small changes to me, both in the category of
> fixing portability/build breakage and thus nominally within the
> policy. Of course the pumpking's ruling is also part of the policy
> and 5.14 now glimmers on the horizon, but since there was no actual
> feedback on Paul's changes, I thought I'd belatedly provide some.

Thanks, Craig.

> The one change to Socket.xs restores buildability anywhere AF_INET6 is
> not defined and looks like it will leave things unchanged anywhere
> that AF_INET6 is defined.

Correct.

> The change to Makefile.SH, while smaller, seems a bit more dangerous.
> If I were to champion this change, I'd want to know why
> $(MINIPERL_EXE) and miniperl both were listed as dependencies in the
> all target in the first place, which should be discernible from git's
> blame feature.

Agreed.

Comment: According to Configure, the only platforms that require an executable suffix are Stratus VOS, DJGPP, OS/2, and Cygwin. On every other platform (clearly the majority of them), this change is a no-op. I was not paying attention when this change went in, or I would have noticed that it broke our build way back when. On the 4 platforms that require an executable suffix, the effect of my patch is to retain "miniperl.pm" (VOS) or "miniperl.exe" (DJGPP, OS/2, Cygwin) as a target, while removing "miniperl" as a target. I only see one reference to a bare "miniperl" that remains in Makefile.SH, in the os/2 section (~line 694). It doesn't use an executable suffix, despite the setting of the _exe variable for OS/2 in configure. This seems inconsistent to me, and I suspect that it is either evidence that the OS/2 port has not been built in a while, or that OS/2 doesn't really care whether the suffix is used or not. I would have expected line 694 to also reference $(MINIPERL_EXE) not miniperl.

I'd be grateful if the maintainer(s) of the DJGPP, OS/2 and Cygwin ports would build perl with this patch in place and report on its effect. I do not think it will have any effect on them, but life is complicated and a simple Configure/Build/Test cycle would prove or disprove my proposed change. At the very least, it would indicate whether perl still builds on those platforms, with or without these changes.

If these ports are no longer maintained, then the question is moot.

Thanks
PG

doughera at lafayette

Oct 4, 2010, 9:10 AM

Post #10 of 17 (531 views)
Permalink

Re: [perl #78132] [PATCH] Fix perl build problems on Stratus VOS [In reply to]

On Mon, 4 Oct 2010, Craig A. Berry wrote:

> On Sun, Oct 3, 2010 at 8:02 PM, Jesse Vincent <jesse [at] fsck> wrote:
>
> >
> > On Sun �3.Oct'10 at 14:22:19 -0700, Father Chrysostomos via RT wrote:
> >> I?m unsure as to the current policy with regard to maintenance patches.
> >> Usually they are cherry-picked from blead. (I don?t know how to do that,
> >> anyway. :-)
> >
> >
> > It's docced in perlpolicy.pod - this looks like a big enough chnage that
> > it probably doesn't qualify for backport to 5.12.

That's a good, sensible, and safe first pass assessment.

But, as Craig sensibly points out, upon more careful examination, this is
the sort of thing that perhaps should be applied. It's on my To-Do list
to take a look.

> It looked like two fairly small changes to me, both in the category of
> fixing portability/build breakage and thus nominally within the
> policy. Of course the pumpking's ruling is also part of the policy
> and 5.14 now glimmers on the horizon, but since there was no actual
> feedback on Paul's changes, I thought I'd belatedly provide some.
>
> The one change to Socket.xs restores buildability anywhere AF_INET6 is
> not defined and looks like it will leave things unchanged anywhere
> that AF_INET6 is defined.
>
> The change to Makefile.SH, while smaller, seems a bit more dangerous.
> If I were to champion this change, I'd want to know why
> $(MINIPERL_EXE) and miniperl both were listed as dependencies in the
> all target in the first place, which should be discernible from git's
> blame feature.

Anyone fluent with git care to enlighten me how to do that efficiently?

--
Andy Dougherty doughera [at] lafayette

ben at morrow

Oct 4, 2010, 10:15 AM

Post #11 of 17 (531 views)
Permalink

Re: [perl #78132] [PATCH] Fix perl build problems on Stratus VOS [In reply to]

Quoth doughera [at] lafayette (Andy Dougherty):
> >
> > The change to Makefile.SH, while smaller, seems a bit more dangerous.
> > If I were to champion this change, I'd want to know why
> > $(MINIPERL_EXE) and miniperl both were listed as dependencies in the
> > all target in the first place, which should be discernible from git's
> > blame feature.
>
> Anyone fluent with git care to enlighten me how to do that efficiently?

Personally I use a modified version of rgs' githistorybrowser.vim
http://github.com/rgs/githistorybrowser ; in general, you do a whole lot
of 'git blame', 'git show' and 'git log -p -n1 <commit>', and it's very
tedious. I suspect if I knew more about it git-log's -S option might be
useful for this sort of thing.

The duplicated 'miniperl$(EXE_EXT) miniperl' (as it was then) was added
by

commit dcff826f70bf3f64ced085d87d733c26aacda219
Author: Yves Orton <demerphq [at] gmail>
Date: Sun Jan 4 16:48:27 2009 +0100

eliminate .patchnum and related infrastrcuture from *nix based build process

Rename the old "unpushed.h" to "git_version.h" and make it hold the defines

and it looks to me like an oversight.

Ben

jesse at fsck

Oct 4, 2010, 10:42 AM

Post #12 of 17 (533 views)
Permalink

Re: [perl #78132] [PATCH] Fix perl build problems on Stratus VOS [In reply to]

> > > It's docced in perlpolicy.pod - this looks like a big enough chnage that
> > > it probably doesn't qualify for backport to 5.12.
>
> That's a good, sensible, and safe first pass assessment.
>
> But, as Craig sensibly points out, upon more careful examination, this is
> the sort of thing that perhaps should be applied. It's on my To-Do list
> to take a look.

Consider my concern withdrawn.

Best,
Jesse

avarab at gmail

Oct 4, 2010, 12:12 PM

Post #13 of 17 (538 views)
Permalink

Re: [perl #78132] [PATCH] Fix perl build problems on Stratus VOS [In reply to]

On Mon, Oct 4, 2010 at 17:15, Ben Morrow <ben [at] morrow> wrote:
> Quoth doughera [at] lafayette (Andy Dougherty):
>> >
>> > The change to Makefile.SH, while smaller, seems a bit more dangerous.
>> > If I were to champion this change, I'd want to know why
>> > $(MINIPERL_EXE) and miniperl both were listed as dependencies in the
>> > all target in the first place, which should be discernible from git's
>> > blame feature.
>>
>> Anyone fluent with git care to enlighten me how to do that efficiently?
>
> Personally I use a modified version of rgs' githistorybrowser.vim
> http://github.com/rgs/githistorybrowser ; in general, you do a whole lot
> of 'git blame', 'git show' and 'git log -p -n1 <commit>', and it's very
> tedious. I suspect if I knew more about it git-log's -S option might be
> useful for this sort of thing.
>
> The duplicated 'miniperl$(EXE_EXT) miniperl' (as it was then) was added
> by

Newer versions (as in ones released ~1 month ago) have support for -G,
which is -S but takes a regex, so this would be:

git log --reverse -p -G 'EXE_EXT[^\n]+miniperl' -- Makefile.SH

Which in this case is the second commit displayed, but --oneline finds
all these:

cd4d8a9 Update for OS/2 support: variable file extensions, invoke
shell explicitly
6189dba Cleanliness inspired by Cygwin.
443a5b9 Makefiles are sloppy about the exe suffix (from Paul Green)
1ed50e5 Remove the newly added makedepend .depending "token
directory" when cleaning up.
cb3fc42 Panther preparation.
1de9afc Make the perl interpreter more tolerant of UTF-16-encoded
script (patch by Jarkko Hietaniemi)
908fcb8 Move DynaLoader.o into libperl.so.
f2534cb miniperl may not have been successfully built before
running a "make distclean".
cef6ea9 miscellanea Message-ID: <4671FA51.4070001 [at] iki>
5a20539 - crosscompilation - step 1 of N+1 Message-ID:
<48C49629.4000208 [at] vkonovalov>
dcff826 eliminate .patchnum and related infrastrcuture from *nix
based build process
e9be352 doesnt quite work yet, but provisional steps towards using
miniperl to do the git stuff
eb5c076 eliminate make_patchnum.sh, and make the build process use
make_patchnum.pl instead
af4015f Correct the over-zealous addition of $(RUN) into test -f
./miniperl$(EXE_EXT) (in change
cef6ea9dde586d23f429802e75d22875450d6b68)
bf799c6 Add a perlmini.o and perlmini.c akin to opmini.o and
opmini.c, for ./miniperl This will allow a defined order for
generating git_version.h and then p
cc69b68 suidperl goes.
344af49 Generate perlapi.pod and perlintern.pod at build time,
instead of shipping them.
6e2cec7 Retire uupacktool.pl. We're not in Kansas^W(Perforce &
APC)-land anymore.
199863e Adopt Makefile macros MINIPERL_EXE and MINIPERL from VMS,
to reduce copy&paste.

So often you might have to go through a lot of things, especially if
you don't know exactly what you're looking for.

doughera at lafayette

Oct 6, 2010, 11:26 AM

Post #14 of 17 (527 views)
Permalink

Re: [perl #78132] [PATCH] Fix perl build problems on Stratus VOS [In reply to]

On Mon, 4 Oct 2010, Jesse Vincent wrote:

>
> > > > It's docced in perlpolicy.pod - this looks like a big enough chnage that
> > > > it probably doesn't qualify for backport to 5.12.
> >
> > That's a good, sensible, and safe first pass assessment.
> >
> > But, as Craig sensibly points out, upon more careful examination, this is
> > the sort of thing that perhaps should be applied. It's on my To-Do list
> > to take a look.

I think this one should go into maint-5.12. I have "Requested" it with
cherrymaint and would appreciate any "seconds". The blead version of the
patch doesn't apply cleanly to maint-5.12, but Paul has supplied a version
that does apply cleanly, so I'd propose just applying that.

--
Andy Dougherty doughera [at] lafayette

doughera at lafayette

Oct 24, 2010, 1:42 PM

Post #15 of 17 (481 views)
Permalink

Re: [perl #78132] [PATCH] Fix perl build problems on Stratus VOS [In reply to]

On Sun, 24 Oct 2010, Father Chrysostomos via RT wrote:

> a5addb1 has been marked as cherry-picked in cherrymaint. But I do not
> see it in the maint-5.12.x branch. Did you choose the wrong menu item?

Yes, that's my fault. I picked "Requested", but later hit the down arrow
trying to scroll through the list of commits and it got switched to
"Cherr-picked" without me noticing. I have since gone back in and tried
to change it back, but I can't. I've been meaning to do something about
that.

In any case, don't worry about it too much since the cherry-picked
patch won't apply cleanly; Paul sent in a separate 5.12.x version which
I plan to apply.

--
Andy Dougherty doughera [at] lafayette

Paul.Green at stratus

Apr 23, 2012, 11:20 AM

Post #16 of 17 (221 views)
Permalink

RE: [perl #78132] [PATCH] Fix perl build problems on Stratus VOS [In reply to]

I am reviewing it now.

PG

-----Original Message-----
From: James E Keenan via RT [mailto:perlbug-followup [at] perl]
Sent: Friday, April 20, 2012 9:01 PM
To: Green, Paul
Subject: [perl #78132] [PATCH] Fix perl build problems on Stratus VOS

On Sun Oct 24 13:42:51 2010, doughera wrote:
>
> In any case, don't worry about it too much since the cherry-picked
> patch won't apply cleanly; Paul sent in a separate 5.12.x version
> which I plan to apply.
>

Should we still be considering any of the patches submitted in this ticket, or are they too stale?

Thank you very much.
Jim Keenan

Paul.Green at stratus

Apr 23, 2012, 5:51 PM

Post #17 of 17 (219 views)
Permalink

RE: [perl #78132] [PATCH] Fix perl build problems on Stratus VOS [In reply to]

blead:

According to previous entries in this report, these patches were applied by sprout on 2010-10-03 (a5addb1). Updated perldelta in 810f3b7.

perl-5.12:

These changes are present in today's copy of perl-5.12. I don't know exactly when this happened.

perl-5.10:

I only proposed to change one file, which is Makefile.SH. These changes were not applied, and they are still valid. I don't know if perl-5.10 is still maintained, but whether or not it is still maintained, I don't think you need to apply this patch. Let sleeping dogs lie, I say.

You can close this bug report.

PG

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads