Upgrade perl

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

@dolmen

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

@kusma

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

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

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.

@Leont

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

@dougwilson

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

@aberumen

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

@csware

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,
Christophe

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.

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

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

@csware

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

@dscho

@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

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

perl: add 0008-Fix-Term-ReadLine.patch

Navigation Menu

Repository navigation

Upgrade perl #61

9 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Upgrade perl #61

Description

Activity

dscho commented on Sep 4, 2012

aberumen commented on Sep 4, 2012

dscho commented on Sep 4, 2012

kusma commented on Sep 4, 2012

dscho commented on Sep 4, 2012

aberumen commented on Sep 4, 2012

dscho commented on Sep 4, 2012

aberumen commented on Sep 4, 2012

dscho commented on Sep 4, 2012

dolmen commented on Sep 4, 2012

aberumen commented on Sep 5, 2012

dscho commented on Sep 5, 2012

aberumen commented on Sep 5, 2012

Leont commented on Nov 22, 2012

dolmen commented on Nov 23, 2012

9 remaining items

sschuberth commented on Jan 18, 2013

sschuberth commented on Jan 18, 2013

csware commented on Feb 1, 2013

patthoyts commented on Feb 5, 2013

sschuberth commented on May 21, 2013

Groovounet commented on Sep 5, 2013

sschuberth commented on Sep 5, 2013

dscho commented on Dec 30, 2013

csware commented on Dec 30, 2013

dscho commented on Dec 30, 2013

csware commented on Jan 2, 2014

dscho commented on Jan 3, 2014

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions