Skip to content
This repository

Upgrade perl #61

Closed
dolmen opened this Issue September 03, 2012 · 36 comments

10 participants

Olivier Mengué dscho aberumen Erik Faye-Lund Leon Timmermans csware Sebastian Schuberth Douglas Christopher Wilson Pat Thoyts Christophe Riccio
Olivier Mengué

The old perl 5.8.8 is included in msysgit. But 5.16.1 is the current stable recommended release.

dscho
Owner

@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!

aberumen

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.

dscho
Owner

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.dll and commit that.

Erik Faye-Lund
Owner

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.

dscho
Owner

@kusma yes, that's what I meant by "an installed Git for Windows" ;-) Thanks for clarifying!

aberumen

Why does libiconv-2.dll go in mingw/bin instead of bin?

dscho
Owner

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.

aberumen

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?

dscho
Owner

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?

Olivier Mengué

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.

aberumen

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.

dscho
Owner

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?

aberumen

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 2

If 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 1
Leon Timmermans

AFAIK 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.

Olivier Mengué

@Leont MinGW is not msys. Building Perl on msys is more like building it on Linux or on cygwin than on native Win32: directory separator is '/', PATH separator is ':'...

Leon Timmermans

I see. In that case, taking this to p5p may help. I see no reason why perl can't support msys out of the box.

Leon Timmermans

It's already in apparently.

Sebastian Schuberth
Owner

@Leont How can the fix by @csware be in msysgit already if there is not even a Perl release including it yet? I guess what @csware meant is that we should backport the upstream patch to whatever Perl version we upgrade to in msysgit unless it is already contained upstream which is supposedly the case with Perl 5.18.

dscho
Owner

I just added the entry I want to upgrade Perl. How do I do that? to https://github.com/msysgit/msysgit/wiki/Frequently-Asked-Questions. Hopefully this is helpful!

Leon Timmermans

@sschuberth: yeah, I meant it's applied to blead. AFAICS porting to 'new' platforms is outside of the scope of a maintenance branch, so I wouldn't count on an official backport. 5.18 is scheduled for may 2013.

csware

Btw. it would be nice if the patch mentioned in #61 (comment) could be applied regardless if the shipped perl version gets upgraded.

Sebastian Schuberth
Owner

@csware Which patch do you mean exactly? You are just referring to this very issue itself.

Douglas Christopher Wilson

@sschuberth I was confused as well, but I think GitHub just marked up the link text weird. The link points to the anchor of the comment with https://rt.perl.org/rt3//Public/Bug/Display.html?id=115900 in it, so I'm sure @csware is referring to the patch in that RT ticket.

Sebastian Schuberth
Owner

@dougwilson Right, thanks. I should have looked more closely.

Sebastian Schuberth
Owner

@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?

csware

Too bad that my proposed patch (https://rt.perl.org/rt3//Public/Bug/Display.html?id=115900) is not in 1.8.2.

Pat Thoyts
Owner

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.

Sebastian Schuberth
Owner

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).

Christophe Riccio

Hi,

Is there a way to use Perl 5.18 with Git MSys ?

Thanks,
Christophe

Sebastian Schuberth
Owner

Not 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.

dscho dscho closed this December 30, 2013
dscho
Owner

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).

csware

Please apply the patch mentioned in #61 (comment) regardless if the shipped perl version gets upgraded.

dscho
Owner

@csware at this point, I am afraid I have to decline. If you want any patch applied, I have to ask you to do what everybody else (including myself) has to do when they want a patch to be applied: open a nicely crafted pull request.

csware

@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
Owner

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.