Closed p5pRT closed 12 years ago
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
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
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.
The RT System itself - Status changed from 'new' to 'open'
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?
"Father Chrysostomos via RT" \perlbug\-followup@​perl\.org 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.
On Sun Oct 03 14:28:06 2010\, rafl@debian.org wrote:
"Father Chrysostomos via RT" \perlbug\-followup@​perl\.org 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.
On Sun Oct 03 14:28:06 2010\, rafl@debian.org wrote:
"Father Chrysostomos via RT" \perlbug\-followup@​perl\.org 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.
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.
On Sun\, Oct 3\, 2010 at 8:02 PM\, Jesse Vincent \jesse@​fsck\.com 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.
Craig A. Berry [mailto:craig.a.berry@gmail.com] wrote:
On Sun\, Oct 3\, 2010 at 8:02 PM\, Jesse Vincent \jesse@​fsck\.com 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
On Mon\, 4 Oct 2010\, Craig A. Berry wrote:
On Sun\, Oct 3\, 2010 at 8:02 PM\, Jesse Vincent \jesse@​fsck\.com 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@lafayette.edu
Quoth doughera@lafayette.edu (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 \
The duplicated 'miniperl$(EXE_EXT) miniperl' (as it was then) was added by
commit dcff826f70bf3f64ced085d87d733c26aacda219 Author: Yves Orton \demerphq@​gmail\.com 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
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
On Mon\, Oct 4\, 2010 at 17:15\, Ben Morrow \ben@​morrow\.me\.uk wrote:
Quoth doughera@lafayette.edu (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 \
'\, 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@​iki\.fi 5a20539 - crosscompilation - step 1 of N+1 Message-ID: \48C49629\.4000208@​vkonovalov\.ru 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.
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@lafayette.edu
On Wed Oct 06 11:27:18 2010\, doughera wrote:
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".
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?
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@lafayette.edu
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
I am reviewing it now.
PG
-----Original Message----- From: James E Keenan via RT [mailto:perlbug-followup@perl.org] 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
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
@cpansprout - Status changed from 'open' to 'resolved'
Migrated from rt.perl.org#78132 (status was 'resolved')
Searchable as RT78132$