Repository navigation
Upgrade perl #61
Description
Activity
@dolmen I am glad you volunteer! Upgrading Perl has been a notorious issue we had for a long time, so it is good to see that someone cares enough to see to it being done.
It involves the following steps:
- install msysGit (the development environment), preferably via the net installer.
- make a shortcut as suggested in the message of the command-line window, to be able to start msysGit later without hassles.
- check out the msys branch, best is to do this from an installed Git for Windows
(cd /c/msysgit && git checkout -t origin/msys). - start msysGit (now in MSys mode).
- patch /src/perl/release.sh to download the appropriate source package.
- start /src/perl/release.sh.
- patch /src/perl/perl-*/ until it compiles (possibly fixing the application of the patches from /src/perl/patches/ which release.sh tries to apply via git am).
- export the new patches to /src/perl/patches/.
- fork msysgit on GitHub.
- push the changes.
- make a pull request.
Thank you in advance!
I'm interested in this issue as well. I attempted the above steps; however, starting msysGit after checking out the msys branch fails with "The program can't start because libiconv-2.dll is missing from your computer." The problem is obvious but how should it be resolved? How is libiconv supplied?
Since the error originates from git.exe, maybe in the transition to unicode the msys branch was not updated to include libiconv?
Edit: As a work around I copied the dll from a Git for Windows install.
You can use Git itself to find the missing files. I just launched "git ls-tree -r origin/devel | grep libiconv-2" and found that there are two instances, both in the mingw/ subtree. So I imagine that libiconv-2 is needed for Git itself to work (which is called to make the prompt informative).
The easiest way to fix this would probably be to call
git checkout origin/devel mingw/bin/libiconv-2.dlland commit that.Then again, how can you use git to solve the problem if git is already broken?
Have a second, non-broken git installation, that's how.
Why does libiconv-2.dll go in mingw/bin instead of bin?
See the What is this "MSys" thing in "MSysGit"? section in https://github.com/msysgit/msysgit/wiki/Frequently-Asked-Questions: it is a MinGW DLL.
I understand the distinction but isn't git.exe also a mingw binary yet it is in /bin?
Also, with regards to a patch in src/perl/patches. The context of a patch has changed drastically in recent Perl versions so it doesn't apply. I'm a bit new to this. How should this be approached? Should I apply the changes in patch manually and commit that?
One more thing. Why is a git repo created in the Perl source tree after untaring?
Yes, git.exe is in /bin/, because Git hard-codes the path of libexec/ into the binary and in the final product, the installed Git for Windows, git.exe lives in /git/. Yes, we have to strike compromises.
The context of the patches has changed, eh? Then it is probably time to try to figure out how to recreate those patches from the commit messages.
The Git repository is initialized so that the patches can be applied easier. After all, I do not want to apply them twice, do I?
The proper thing to do is to rebuild the patches and get most of them merged upstream in the perl sources to avoid to rewrite them here at the next perl release...
Setting up the msysgit environment is quite hard, and I'm not sure mine is right yet.
I managed to apply most of the patches onto 5.16.1 with the exception on 1 or 2 and some MacOSX only changes that I choose to omit.
Trying to build results in a error :(. Miniperl cannot be found. Make complains about a circular dependency between miniperl and Config_git.pl.
I'm not familiar with the Perl build system so I need a bit of help with this one.
On Wed, 5 Sep 2012, aberumen wrote:
I managed to apply most of the patches onto 5.16.1 with the exception on 1 or 2 and some MacOSX only changes that I choose to omit.
Maybe you could commit the fixed patches to /src/perl/patches/ and publish it as a work-in-progress branch?
Trying to build results in a error :(. Miniperl cannot be found. Make complains about a circular dependency between miniperl and Config_git.pl.
That is usually due to two Makefile targets differing only in case (such as "headers" vs "HEADERS").
Could you paste the exact error message? Maybe there is a hint what might be the culprit?
I've pushed my changes to the work/perl-5.16.1 branch of my fork.
Error from make:
GNUmakefile:386: warning: overriding commands for target `perlmain.o' GNUmakefile:327: warning: ignoring old commands for target `perlmain.o' make install.perl install.man STRIPFLAGS= DESTDIR="" make[1]: Entering directory `/src/perl/perl-5.16.1' GNUmakefile:386: warning: overriding commands for target `perlmain.o' GNUmakefile:327: warning: ignoring old commands for target `perlmain.o' make[1]: Circular lib/Config_git.pl <- miniperl.exe dependency dropped. PATH="/src/perl/perl-5.16.1:.:/c/Users/me/bin:.:/usr/local/bin:/bin :/mingw/bin:/c/windows/system32:/c/windows:/c/windows/System32/Wbem:/c/windows/S ystem32/WindowsPowerShell/v1.0/:/c/Program\ Files\ (x86)/ATI\ Technologies/ATI.A CE/Core-Static:/c/Program\ Files\ (x86)/AMD\ APP/bin/x86_64:/c/Program\ Files\ ( x86)/QuickTime/QTSystem/:/c/Python27:/c/Program\ Files\ (x86)/Microsoft\ SQL\ Se rver/100/Tools/Binn/:/c/Program\ Files/Microsoft\ SQL\ Server/100/Tools/Binn/:/c /Program\ Files/Microsoft\ SQL\ Server/100/DTS/Binn/:/c/Program\ Files\ (x86)/Su bversion/bin:/c/Program\ Files\ (x86)/Notepad++:/c/Program\ Files\ (x86)/GTK2-Ru ntime/bin:/usr/bin:/etc:/usr/lib:/lib:/usr/libexec" ./miniperl.exe -Ilib make_p atchnum.pl /bin/sh: ./miniperl.exe: No such file or directory make[1]: *** [lib/Config_git.pl] Error 127 make[1]: Leaving directory `/src/perl/perl-5.16.1' make: *** [install] Error 2If I run 'make miniperl' the output is
GNUmakefile:386: warning: overriding commands for target `perlmain.o' GNUmakefile:327: warning: ignoring old commands for target `perlmain.o' make: Circular miniperl.exe <- libcygperl5_16_1.a dependency dropped. PATH="/src/perl/perl-5.16.1:.:/c/Users/me/bin:.:/usr/local/bin:/bin :/mingw/bin:/c/windows/system32:/c/windows:/c/windows/System32/Wbem:/c/windows/S ystem32/WindowsPowerShell/v1.0/:/c/Program\ Files\ (x86)/ATI\ Technologies/ATI.A CE/Core-Static:/c/Program\ Files\ (x86)/AMD\ APP/bin/x86_64:/c/Program\ Files\ ( x86)/QuickTime/QTSystem/:/c/Python27:/c/Program\ Files\ (x86)/Microsoft\ SQL\ Se rver/100/Tools/Binn/:/c/Program\ Files/Microsoft\ SQL\ Server/100/Tools/Binn/:/c /Program\ Files/Microsoft\ SQL\ Server/100/DTS/Binn/:/c/Program\ Files\ (x86)/Su bversion/bin:/c/Program\ Files\ (x86)/Notepad++:/c/Program\ Files\ (x86)/GTK2-Ru ntime/bin:/usr/bin:/etc:/usr/lib:/lib:/usr/libexec" gcc -L/src/perl/perl-5.16.1 -s -o miniperl miniperlmain.o opmini.o -Wl,-Bstatic -lcygperl5_16_1 -Wl,-Bdynam ic /bin/../lib/gcc-lib/i686-pc-msys/2.95.3-1/../../../../i686-pc-msys/bin/ld: canno t find -lcygperl5_16_1 collect2: ld returned 1 exit status make: *** [miniperl.exe] Error 1AFAIK Strawberry Perl is also based on MingW, I suspect there's a lot of overlap between what you guys are doing and what they are doing.
9 remaining items
@dougwilson Right, thanks. I should have looked more closely.
@aberumen I'm unable to find your fork on GitHub. What's the state of your efforts to upgrade Perl? I also realize @patthoyts has a work/pt/perl branch (for version 5.12.2). What's the state of that one?
Too bad that my proposed patch (https://rt.perl.org/rt3//Public/Bug/Display.html?id=115900) is not in 1.8.2.
The pt/perl branch is based off master (from release 1.7.3.1) and was an experiment in using a mingw build of perl with git for windows. There were a number of problems and thats when I discovered that we actually use a msys build of perl.
Possibly this can be re-used to get some upgraded build - it looks like a release script and a makefile patch is all it has.FYI, the patch by @csware is in upstream Perl 5.18 which was just released (in fact it also already was in Perl 5.17.7).
Hi,
Is there a way to use Perl 5.18 with Git MSys ?
Thanks,
ChristopheNot officially (yet). You would need to build Perl yourself, which is not so easy on MSYS. The patches at https://github.com/Alexpux/MSYS2-Tools/tree/master/perl/5.18.0 and the build files inside http://lrn.no-ip.info/other/mingw/msys/perl/5.8.8-0RC1/perl-5.8.8-1-msys-1.0.16-src.tar.lzma might be of some help to get you started. BTW, the mingwGitDevEnv-packages project is aiming at providing updated packages for MSYS / Git for Windows. It is planned to provide updated Perl packages as part of that project, but work on Perl has not yet started.
There is really more than enough information provided here for people who are really, really interested in a newer Perl, interested enough to actually go and do the work themselves (as opposed to expect others to do it). Looking at this issue as a scientific test, there is now enough evidence that this issue can be closed without resolution (at least until someone comes along who wants to surprise me positively).
@dscho: Nice, when I reported it the last time it was said that you do not apply local patches to shipped stuff (https://groups.google.com/forum/#!topic/msysgit/oHDBhnAHIe4).
Okay, see PR #152.
@dscho: Nice, when I reported it the last time it was said that you do not apply local patches to shipped stuff
Well, yes, sorry. I tried to be a little more stringent (making maintenance easier) but I see that it would harm usability if we would not have that patch. So while it is technically wrong (our Perl still reports to be 5.8 but is technically 5.8+patch) it is still better than the alternative, right?
So: thanks for keeping prodding me and for your patience to see this fix through.
- added a commit that references this issue
on Apr 26, 2014 - added a commit that references this issue
on May 18, 2014
The old perl 5.8.8 is included in msysgit. But 5.16.1 is the current stable recommended release.