From: Charles W. <cwi...@us...> - 2011-04-27 14:53:28
|
I'm pleased to announce that msys-perl has been updated from the 10-year-old 5.6.1 (April 9, 2001), to the young and spry 5.8.8 (Feb 2, 2006). To install or upgrade: mingw-get update mingw-get upgrade msys-perl-bin mingw-get upgrade msys-perl-man (optional) mingw-get upgrade msys-perl-html (optional) mingw-get upgrade msys-perl-doc (optional) mingw-get upgrade msys-perl-lic (optional) Obviously, you may need to use 'mingw-get install' instead of 'mingw-get upgrade' if you do not currently have msys-perl installed. REQUIREMENTS ================== This build contains a workaround for a POSIX-allowable but unexpected msys behavior in MSYS-1.0.16 and earlier. However, best results will be obtained using MSYS-1.0.17 or later. For more information, see: http://thread.gmane.org/gmane.comp.gnu.mingw.user/35771/focus=35793 There are new runtime dependencies: msys-libbz2-dll msys-libexpat-dll msys-libxml2-dll to go along with the existing ones that perl-5.6.1 had msys-zlib-dll msys-libgdbm-dll msys-libcrypt-dll msys-core-bin These will be installed automatically by mingw-get if you do not already have them installed. In addition, the perlrebase script needs the following, but they will NOT be installed automatically by mingw-get. If you don't already have them installed, you'll need to install them manually via 'mingw-get install': msys-findutils-bin msys-grep-bin msys-sed-bin msys-rebase-bin EITHER mingw32-binutils-bin OR msys-binutils-bin Most installations will already have these packages, except perhaps msys-rebase-bin. ACKNOWLEDGMENTS ================== This updated perl release would not have been possible without the earlier efforts of the msysgit folks, who have long provided a similar port of perl-5.8.8 for their fork of the msys environment. In addition, the efforts of LRN were invaluable: (a) providing an initial port to OUR version of msys of perl-5.8.8, (b) tracking down and debugging many newly discovered porting mishaps of the new perl on msys, in both perl proper, the various extensions, and even in MSYS itself, (c) providing updated versions of the build script which greatly simplified package creation, given the issues related to DESTDIR installs on msys, and (d) prodding me to finally get this release published for general use. Finally, Reini Urban, the cygwin-perl maintainer, provided assistance (and example code, patches, and buildscripts), both on several mailing lists and via his old cygwin perl-5.8.8-4 package. CHANGES ================== The new release provides many improvements over the older version. The following is a list culled from http://dev.perl.org/perl5/news/2002/07/18/580ann/ and summarizes the changes from the 5.6.x series to the 5.8.x series. For changes between minor revisions in the 5.8.x series, see http://search.cpan.org/dist/perl/pod/perl581delta.pod http://search.cpan.org/dist/perl/pod/perl582delta.pod http://search.cpan.org/dist/perl/pod/perl583delta.pod http://search.cpan.org/dist/perl/pod/perl584delta.pod http://search.cpan.org/dist/perl/pod/perl585delta.pod http://search.cpan.org/dist/perl/pod/perl586delta.pod http://search.cpan.org/dist/perl/pod/perl587delta.pod http://search.cpan.org/dist/perl/pod/perl588delta.pod For MSYS-specific changes see the appropriate heading below. PERL-5.8.x CHANGES ================== - New IO Implementation: the new PerlIO implementation is both a portable stdio implementation (at the source code level) and a flexible new framework for richer I/O behaviours - Better Numeric Accuracy: previous Perls relied on vendors' string-to-number and back routines which in some cases proved to be too much trust leading to nonportable and wrong behaviours - 64-bit support: 64-bit support is now considered to be mature -- if your platform supports 64-bit integers or address space, you can compile Perl to use those. (MSYS-PERL is compiled to support 64bit ints) - Safe Signals: in previous versions of Perl signals could corrupt Perl's internal state - Many New Modules: Digest::MD5, File::Temp, Filter::Simple, libnet, List::Util, Memoize, MIME::Base64, Scalar::Util, Storable, Switch, Test::More, Test::Simple, Text::Balanced, Tie::File, ... - Extensive Regression Testing: Perl has now almost six times as many tests as in 5.6, and the code is test built daily on several platforms - Better Unicode Support (NOT APPLICABLE TO MSYS-PERL) - New Threads Implementation (NOT APPLICABLE TO MSYS-PERL) Incompatibilities - BINARY INCOMPATIBLE: mainly because of the PerlIO introduction, Perl 5.8 is not binary compatible with any earlier Perl release, XS MODULES WILL HAVE TO BE RECOMPILED! - Hashing Order Changed Once Again: the function used in the implementation of hashes was changed to a better one once again, but your code shouldn't be expecting any particular key ordering - Attributes For my Now Handled At Run-Time: the attributes for my() are now run-time, as opposed to compile time - REF(...) instead of SCALAR(...): to be consistent with ref()'s results, references to references now stringify as "REF(...)" Nomenclature Change - What the "Camel III" book called an "IO discipline" is now called an "IO layer" Deprecations - dump(): the functionality of the dump command is now considered obsolete - Pseudohashes: the user-visible implementation of pseudohashes is going to be removed and replaced with something cleaner (also, the internal implementation will have to go since it was found to slow down the overall hash access) - Use of tainted data in exec LIST and system LIST: now gives a warning, but will become fatal error in a future release - tr///C, tr///U: the interface was found to be a mistake, pack("C0", ...) and pack("U0", ...) can be used instead Known Problems - The Compiler Suite: bytecompiling and compiling still do not work - Lvalue subroutines: still experimental - Interaction of local() and tie(): the exact semantics are still in flux - Tied/Magical Array/Hash Elements Do Not Autovivify - Self-tying arrays and hashes: currently explicitly disallowed MSYS-PERL CHANGES ================== Relative to msys-perl-5.6.1_2-2, this new perl release contains a large number of additional modules. Some, as noted above, were imported into perl core upstream in the 5.8.x series; others were added to the msys distribution as necessary prerequisites of a working CPAN. Due to the increased number of extensions, AND the fact that a good percentage of them are XS (that is, C-based) extensions and provide DLLs, msys-perl is now subject to the dreaded 'sync_with_child' problem long suffered by modern perl on the cygwin platform. We have adopted a "solution" similar to theirs. msys-perl now ships with a 'perlrebase' script, which can be used to manipulate the ImageBase address of all of those perl-related DLLs, so that they do not overlap. This should fix any "sync_with_child" issues *RELATED TO PERL*. Other sync_with_child problems must be addressed using the full 'rebaseall' procedure; see the rebase documentation for more info. Note that if you use CPAN to install additional modules, you may also need to re-run 'perlrebase' after installing XS extensions. In addition, the 'test' phase of the CPAN installation may fail. - This release is compiled using -DDEBUGGING, which allows the use of the -D* perl commandline options. This has a slight runtime performance impact, but the added convenience is worth the cost, IMO. See `perldoc perlrun' - msys-perl now supports 64bit wide scalar values - msys-perl does NOT support multithreaded operation. MSYS's own threading support is too primitive for perl's needs. - Bundled extensions: the following list was adopted from cygwin's perl-5.8.8-4 package set. Algorithm-Diff-1.1902 Module-Build-0.2808 Alias-2.32 Module-ScanDeps-0.75 Archive-Tar-1.32 Module-Signature-0.55 Archive-Zip-1.20 Net-Telnet-3.03 B-Generate-1.09 PadWalker-1.5 Compress-Bzip2-2.09 PAR-Dist-0.23 Compress-Raw-Bzip2-2.005 Pod-Coverage-0.18 Compress-Raw-Zlib-2.005 Pod-Escapes-1.04 Compress-Zlib-2.005 podlators-2.0.5 Config-Tiny-2.10 Pod-Readme-0.09 CPAN-1.9102 Pod-Simple-3.05 CPAN-Reporter-0.44 Probe-Perl-0.01 Devel-Symdump-2.07 Proc-ProcessTable-0.41 Digest-SHA-5.45 Regexp-Common-2.120 ExtUtils-CBuilder-0.19 Tee-0.13 ExtUtils-ParseXS-2.18 TermReadKey-2.30 File-Copy-Recursive-0.33 Term-ReadLine-Gnu-1.16 File-HomeDir-0.65 Term-ReadLine-Perl-1.0302 File-pushd-0.99 Test-Pod-1.26 File-Temp-0.18 Test-Pod-Coverage-1.08 Getopt-Long-2.36 Test-Reporter-1.27 HTML-Parser-3.56 Text-Diff-0.35 HTML-Tagset-3.10 URI-1.35 IO-CaptureOutput-1.03 version-0.7203 IO-Compress-Base-2.005 Win32API-File-0.1001 IO-Compress-Bzip2-2.005 XML-LibXML-1.63 IO-Compress-Zlib-2.005 XML-LibXML-Common-0.13 IO-String-1.08 XML-NamespaceSupport-1.09 IO-Zlib-1.05 XML-Parser-2.34 IPC-Run3-0.037 XML-SAX-0.15 libwww-perl-5.805 YAML-0.62 Math-BigInt-FastCalc-0.15 YAML-Syck-0.88 MD5-2.03 - Test results: perl core (after removing 'taint' failures) Failed 7/989 test scripts, 99.29% okay. 75/116701 subtests failed, 99.94% okay. The remaining failures are mostly related to symlinks. See the release notes for more information: http://sourceforge.net/projects/mingw/files/MSYS/perl/perl-5.8.8-1/ - Test results: extensions All tests passed, except for minor failures in five of the bundled extensions. - Internal: msys-perl-5.6.1 was shipped with a giant mega patch. msysgit's perl-5.8.8 cherry picked portions of that patch, but still provided it as a monolithic lump, and then shipped a few minor additional patches on top of that. This version decomposed these porting patches into a large number of smaller, fine grained patches, each with a specific focus (functional: "fix build system", or 'area-related': "msys patches for the FOO extension"). It is hoped that this will ease any future ports of newer perls by making the task of forward porting the old patches somewhat less daunting. As a side effect of this 'split the patches' effort, many pieces were found to be unnecessary, and were discarded thus simplifying further the msys port of perl. ABOUT VERSIONS =================== Why perl-5.8.8 and not perl-5.8.9? or 5.10.x, or 5.12.x -- or the soon to be released 5.14.0? Several reasons: 1) msysgit had already demonstrated that a port of 5.8.8 to msys was possible, and suitably reliable for production work. 2) Similarly, msysgit has demonstrated that perl-5.8.8 is sufficiently new to support many modern perl scripts, especially those bundled with 'git' -- an important short term goal for MinGW/MSYS is to provide a working msys port of git (msysgit's port, despite the project name, is actually a *native* MinGW version). 3) Walk before you run. There were enough issues, especially related to the sync_with_child problem, simply getting perl-5.8.8 to work. All of these issues become more and more complex, with the newer perl releases...so, we tackle the problem where it is easier to solve (5.8.x) before moving on to the later perl releases. Now, this is not to say that we do, or do not, plan to release 5.[10|12|14].x perls for msys at some time in the future. We may, but the timeline is completely up in the air. I can say that it probably won't be very soon. Why the particular versions of extensions listed above? Isn't CPAN-1.9102 very old? Yes. Yes it is. However, these versions were chosen because (a) they were current when cygwin's perl-5.8.8-4 package was release, so we KNOW they work correctly with 5.8.8 and don't require features from newer perl, and (b) cygwin-perl-5.8.8-4 already provides any necessary patches for these versions of the extensions, not other versions. You are certainly welcome to update your local install by using CPAN to d/l, compile, and install newer versions of any of these extensions -- but be aware of the sync_with_child issue related to XS extensions, described above. -- Chuck |
From: David G. <DGr...@am...> - 2011-04-27 15:14:30
|
________________________________ From: Charles Wilson [mailto:cwi...@us...] Sent: Wednesday, April 27, 2011 9:53 AM To: MinGW Users List Subject: [Mingw-users] Updated: msys-perl-5.8.8-1 I'm pleased to announce that msys-perl has been updated from the 10-year-old 5.6.1 (April 9, 2001), to the young and spry 5.8.8 (Feb 2, 2006). To install or upgrade: mingw-get update mingw-get upgrade msys-perl-bin mingw-get upgrade msys-perl-man (optional) mingw-get upgrade msys-perl-html (optional) mingw-get upgrade msys-perl-doc (optional) mingw-get upgrade msys-perl-lic (optional) Obviously, you may need to use 'mingw-get install' instead of 'mingw-get upgrade' if you do not currently have msys-perl installed. ... huge snip ... When I tried the upgrade I got a huge swarm of messages like the one below. I have never seen this before, all previous mingw and msys upgrades and installs have worked perfectly. mingw-get: *** WARNING *** c:\mingw\/msys/1.0/lib/perl5/5.6/unicode/In/IPAExtensions.pl:unlink failed; Permission denied |
From: Charles W. <cwi...@us...> - 2011-04-27 18:14:26
|
On 4/27/2011 11:12 AM, David Gressett wrote: > When I tried the upgrade I got a huge swarm of messages like the one > below. I have never seen this before, > all previous mingw and msys upgrades and installs have worked perfectly. > mingw-get: *** WARNING *** > c:\mingw\/msys/1.0/lib/perl5/5.6/unicode/In/IPAExtensions.pl:unlink > failed; Permission denied It seems this is because both the perl-5.6.1-*-bin tarball AND the new perl-5.8.8-1-bin tarball have files like this: 5.8.8: -r-xr-xr-x user/group 7236 2011-04-27 00:23 bin/config_data -r--r--r-- user/group 838 2011-04-27 00:24 lib/perl5/5.8/abbrev.pl 5.6.1: -r-xr-xr-x user/group 119 2010-01-30 14:41 bin/cpan -r--r--r-- user/group 838 2010-01-30 14:35 lib/perl5/5.6/abbrev.pl That is, inside the tarball the file is listed with no write permission. The list of such files with missing write perms is different between the two releases, but there is some overlap. When mingw-get unpacks these tarballs, the affected file(s) are created like this: cygwin reports: -r-xr-xr-x+ 1 user group 7.1K Apr 27 10:10 bin/config_data -r-xr-xr-x+ 1 user group 838 Apr 27 10:10 lib/perl5/5.8/abbrev.pl msys reports: -r-xr-xr-x 1 user group 7236 Apr 27 10:10 /bin/config_data -r--r--r-- 1 user group 838 Apr 27 10:10 /lib/perl5/5.8/abbrev.pl windows gui properties reports: config_data: The Read-only attribute is checked. abbrev.pl: Ditto. I think this is a bug in mingw-get's 'remove' operation. If it can create the file, when running as user A, then it should be able to delete the same file, when running as that same user A. I think mingw-get should be modified to check if a to-be-removed file is "read only" and remove the read-only attribute before trying to delete it. Only if THAT sequence fails should it report a problem to the user. But...that doesn't help you right now! A quick and dirty workaround is: cd / find bin -type f -print0 | xargs -0 chmod u+w find lib/perl5 -type f -print0 | xargs -0 chmod u+w find share/man -type f -print0 | xargs -0 chmod u+w find share/doc -type f -print0 | xargs -0 chmod u+w and then mingw-get upgrade msys-perl-[whatever] -- Chuck |
From: Earnie <ea...@us...> - 2011-04-27 15:23:51
|
David Gressett wrote: > When I tried the upgrade I got a huge swarm of messages like the one below. I have never seen this before, > all previous mingw and msys upgrades and installs have worked perfectly. > mingw-get: *** WARNING *** c:\mingw\/msys/1.0/lib/perl5/5.6/unicode/In/IPAExtensions.pl:unlink failed; Permission denied Do you have something using the file? Windows will not unlink an opened file. -- Earnie -- http://www.for-my-kids.com |
From: David G. <DGr...@am...> - 2011-04-27 16:36:23
|
________________________________ From: Earnie [mailto:ea...@us...] Sent: Wednesday, April 27, 2011 10:24 AM To: MinGW Users List Subject: Re: [Mingw-users] Updated: msys-perl-5.8.8-1 David Gressett wrote: > When I tried the upgrade I got a huge swarm of messages like the one below. I have never seen this before, > all previous mingw and msys upgrades and installs have worked perfectly. > mingw-get: *** WARNING *** c:\mingw\/msys/1.0/lib/perl5/5.6/unicode/In/IPAExtensions.pl:unlink failed; Permission denied Do you have something using the file? Windows will not unlink an opened file. -- Earnie -- http://www.for-my-kids.com It seems unlikely. I haven't used msys at all since my last reboot, and the msys bin directory is not in my Windows path, The new version seems to have installed. I started msys and tried perl --version and it informed me that 5.8.8 is the installed perl. I tried the upgrade again. Usually, a duplicate mingw-get upgrade just removes the stuff being upgraded and immediately puts it back again, but this time I got a very similar swarm of error messages, but they all referred to the new 5.8.8 files. |
From: LRN <lr...@gm...> - 2011-04-27 15:58:15
|
On 27.04.2011 18:53, Charles Wilson wrote: > an important short term goal for MinGW/MSYS is to > provide a working msys port of git (msysgit's port, despite the > project name, is actually a *native* MinGW version). After poking git for a couple of weeks i can state the following: 1) mingw-git can be built completely from the source (from msysgit.git) with existing mingw packages and some new ones, which are also built with mingw (contrary to what msysgit devs do: they're using pre-built binaries, or ancient mingw/msys binaries half of the time). And it works well enough, i'm using it right now (although since i'm not a git guru, my use of git tends to be simple). You can even get a diff for mainline git by diffing msysgit.git against it (the diff is extensive, but manageable, especially if generated files and file moves are filtered out). 2) git itself requires very little to build (besides what msys already has, curl is needed for http access, and tcl/tk/wish - for gitk and git-gui, unless you only want command-line), but will call external applications for some things. For example, git-svn requires svn. And msys-svn would pull the whole lot of dependencies, first of all - Apache Runtime (apr and apr-util), which is, IMO, ill-suited to be built against Msys (apr is portable -> to build against Msys you'd have to patch it considerably to make it "forget" that it can run on Windows and to force it to use Msys' POSIX compatibility layer instead). So providing complete git with all the bells and whistles might be too much for Msys. OTOH, besides svn i haven't found any really difficult dependencies yet. |
From: Hoyt, D. <ho...@ll...> - 2011-04-27 19:23:49
|
> This build contains a workaround for a POSIX-allowable but unexpected > msys behavior in MSYS-1.0.16 and earlier. However, best results will be > obtained using MSYS-1.0.17 or later. Is there an updated msys-core available via mingw-get? A fresh install for me still pulls 1.0.16. I see that on sourceforge it's up and available -- just not through mingw-get for some reason. BTW, you guys deserve a round of applause because I know it was a lot of hard work getting perl whipped into shape for this. It's very welcome, though. Thanks again! |
From: Charles W. <cwi...@us...> - 2011-04-27 19:48:01
|
On 4/27/2011 3:23 PM, Hoyt, David wrote: >> This build contains a workaround for a POSIX-allowable but unexpected >> msys behavior in MSYS-1.0.16 and earlier. However, best results will be >> obtained using MSYS-1.0.17 or later. > > Is there an updated msys-core available via mingw-get? A fresh > install for me still pulls 1.0.16. I see that on sourceforge it's up > and available -- just not through mingw-get for some reason. Well, in a non-fresh install you need to first do mingw-get update to download the latest package manifest data. In a "fresh" install **using the mingw-get-inst GUI** you need to check the "Download latest repository catalogues" box on the "Repository Catalogues" page. Otherwise, you're stuck with a snapshot of the package data as of 20110316 -- as of that date, neither msys-1.0.17 nor perl-5.8.8 had yet been released, so they don't appear in that old manifest data. In a "fresh" install where you manually unpack mingw-get itself, part of the process is to run 'mingw-get update' first, so that probably doesn't correspond to your situation. -- Chuck |
From: Hoyt, D. <ho...@ll...> - 2011-04-27 20:05:36
|
> Well, in a non-fresh install you need to first do > mingw-get update > to download the latest package manifest data. That's the very first step I do after an install and after doing that, it still wasn't pulling the latest msys-core. Examining http://sourceforge.net/projects/mingw/files/Automated%20MinGW%20Installer/mingw-get/catalogue/msys-core.xml.lzma (and uncompressing it) shows that it also still references 1.0.16. Unless, somehow, a server around here has cached a stale copy of it... Can anyone confirm what I'm seeing? |
From: Hoyt, D. <ho...@ll...> - 2011-04-27 20:11:52
|
> That's the very first step I do after an install and after doing that, it still wasn't pulling the latest msys-core. Examining http://sourceforge.net/projects/mingw/files/Automated%20MinGW%20Installer/mingw-get/catalogue/msys-core.xml.lzma (and uncompressing it) shows that it also still references 1.0.16. Unless, somehow, a server around here has cached a stale copy of it... > > Can anyone confirm what I'm seeing? Sorry -- nevermind -- it appears that the sourceforge mirror I had been assigned had the wrong file cached. I switched to a different mirror and the correct msys-core was referenced. Is there an option/env-var in mingw-get to select a different sourceforge mirror? |
From: Earnie <ea...@us...> - 2011-04-27 20:29:00
|
Hoyt, David wrote: >> That's the very first step I do after an install and after doing that, it still wasn't pulling the latest msys-core. Examining http://sourceforge.net/projects/mingw/files/Automated%20MinGW%20Installer/mingw-get/catalogue/msys-core.xml.lzma (and uncompressing it) shows that it also still references 1.0.16. Unless, somehow, a server around here has cached a stale copy of it... >> >> Can anyone confirm what I'm seeing? > > Sorry -- nevermind -- it appears that the sourceforge mirror I had been assigned had the wrong file cached. I switched to a different mirror and the correct msys-core was referenced. Is there an option/env-var in mingw-get to select a different sourceforge mirror? > You can set a default mirror in SourceForge UI. I don't know if that'll help. -- Earnie -- http://www.for-my-kids.com |
From: Reini U. <ru...@x-...> - 2011-04-28 08:32:28
|
2011/4/27 Charles Wilson <cwi...@us...>: > I'm pleased to announce that msys-perl has been updated from the > 10-year-old 5.6.1 (April 9, 2001), to the young and spry 5.8.8 (Feb 2, > 2006). > > To install or upgrade: > mingw-get update Which netinet/in.h did you use? When compiling an extension I get: d:/MinGW/msys/1.0/lib/perl5/5.8/msys/CORE/perl.h:925:27: fatal error: netinet/in.h: No such file or directory $ grep -2 netinet /usr/lib/perl5/5.8/msys/CORE/config.h /* I_NETINET_IN: * This symbol, if defined, indicates to the C program that it should * include <netinet/in.h>. Otherwise, you may try <sys/in.h>. */ #define I_NETINET_IN /**/ -- /* I_NETINET_TCP: * This symbol, if defined, indicates to the C program that it should * include <netinet/tcp.h>. */ #define I_NETINET_TCP /**/ But I have no netinet subdir in my search path, all my msys packages are upgraded,, and the cygwin version includes #include <cygwin/in.h> which perl should not use, rather winsock2. mingw also has no arpa/inet.h and sys/times.h, ... but config.h defines all these. I undef'd those in config.h I_NETINET_IN I_ARPA_INET I_SYS_TIMES I_SYS_IOCTL I_IEEEFP But furthermore the package misses all /usr/lib/perl5/5.8/msys/CORE/win32*.h headers HAS_SOCKET: #if defined(HAS_SOCKET) && !defined(VMS) && !defined(WIN32) /* VMS/WIN32 handle sockets via vmsish.h/win32.h */ # include <sys/socket.h> but WIN32 is not defined in msys and we have no sys/socket.h So we should check for some MSYS define. $ echo|gcc -E -dM -|grep MSYS $ echo|gcc -E -dM -|grep MING #define __MINGW32__ 1 Furthermore: /* undef WIN32 when building on Cygwin (for libwin32) - gph */ #if defined(__CYGWIN__) || defined(__MSYS__) # undef WIN32 # undef _WIN32 #endif 1. __MSYS__ is not defined in gcc 2. MSYS should not undef WIN32 For 5.6 I added arpa/inet.h, sys/socket.h and all win32.h headers to the CORE dir. Furthermore gcc/mingw32/4.5.2 does not look like to have sigjmp_buf, only typedef int jmp_buf[16]; So I undef'd /*#define HAS_SIGSETJMP / **/ also Then it compiles, but I got two missing syms: C.o:C.c:(.text+0x55): undefined reference to `_imp__PL_sys_intern' C.o:C.c:(.text+0x7c): undefined reference to `_imp__win32_async_check' -- Reini Urban http://phpwiki.org/ http://murbreak.at/ |
From: Earnie <ea...@us...> - 2011-04-28 11:59:06
|
Reini Urban wrote: > 2011/4/27 Charles Wilson <cwi...@us...>: >> I'm pleased to announce that msys-perl has been updated from the >> 10-year-old 5.6.1 (April 9, 2001), to the young and spry 5.8.8 (Feb 2, >> 2006). >> >> To install or upgrade: >> mingw-get update > > Which netinet/in.h did you use? > > When compiling an extension I get: > d:/MinGW/msys/1.0/lib/perl5/5.8/msys/CORE/perl.h:925:27: fatal error: > netinet/in.h: No such file or directory > This perl is an MSYS dependent package so extensions would need to be created in the MSYS developer environment. See the www.mingw.org/wiki/HOWTO and pay attention to ``MSYS HOWTOs'' section for setting up an MSYS build environment. -- Earnie -- http://www.for-my-kids.com |
From: Charles W. <cwi...@us...> - 2011-04-28 12:57:41
|
On 4/28/2011 4:32 AM, Reini Urban wrote: > 2011/4/27 Charles Wilson <cwi...@us...>: >> I'm pleased to announce that msys-perl has been updated from the >> 10-year-old 5.6.1 (April 9, 2001), to the young and spry 5.8.8 (Feb 2, >> 2006). >> >> To install or upgrade: >> mingw-get update > > Which netinet/in.h did you use? /usr/include/netinet/in.h. It's part of msys-core-dev. > /* I_NETINET_TCP: > * This symbol, if defined, indicates to the C program that it should > * include <netinet/tcp.h>. > */ > #define I_NETINET_TCP /**/ $ ls /usr/include/netinet/ in.h in_systm.h ip.h ip_icmp.h tcp.h > But I have no netinet subdir in my search path, all my msys packages > are upgraded,, > and the cygwin version includes #include <cygwin/in.h> which perl > should not use, rather winsock2. No, this is an *msys* perl. Not a native perl. That "cygwin/in.h" is what msys uses. MSYS, as a cygwin fork, still uses "cygwin" in a lot of places where it probably should use "msys". 1) You probably haven't installed msys-core-dev. It is not installed by default. 2) You appear to be attempting to build your extension from within an regular MINGW32 shell -- e.g. uname returns MINGW32_NT-6.0 or similar. You MUST build extensions from an MSYSDVLPR shell. > mingw also has no arpa/inet.h and sys/times.h, ... but config.h > defines all these. Right: mingw doesn't have those. msys does: $ ls /usr/include/arpa/ ftp.h inet.h nameser.h nameser_compat.h telnet.h tftp.h $ ls /usr/include/sys/t* /usr/include/sys/termio.h /usr/include/sys/time.h /usr/include/sys/times.h /usr/include/sys/types.h /usr/include/sys/termios.h /usr/include/sys/timeb.h /usr/include/sys/ttychars.h > I undef'd those in config.h > I_NETINET_IN > I_ARPA_INET > I_SYS_TIMES > I_SYS_IOCTL > I_IEEEFP > > But furthermore the package misses all > /usr/lib/perl5/5.8/msys/CORE/win32*.h headers Ermm...why should it? Cygwin doesn't have those in /usr/lib/perl5/5.10/i686-cygwin/CORE/ either. > HAS_SOCKET: > #if defined(HAS_SOCKET) && !defined(VMS) && !defined(WIN32) /* > VMS/WIN32 handle sockets via vmsish.h/win32.h */ > # include <sys/socket.h> > but WIN32 is not defined in msys and we have no sys/socket.h $ ls /usr/include/sys/socket.h /usr/include/sys/socket.h > So we should check for some MSYS define. > > $ echo|gcc -E -dM -|grep MSYS > > $ echo|gcc -E -dM -|grep MING > #define __MINGW32__ 1 Wrong gcc -- that's /mingw/bin/gcc. In an MSYSDVLPR shell, /usr/bin will precede in PATH, and /usr/bin/gcc reports: $ echo|gcc -E -dM - | grep MSYS #define __MSYS__ 1 $ echo|gcc -E -dM - | grep MING > Furthermore: > /* undef WIN32 when building on Cygwin (for libwin32) - gph */ > #if defined(__CYGWIN__) || defined(__MSYS__) > # undef WIN32 > # undef _WIN32 > #endif > > 1. __MSYS__ is not defined in gcc Yes, it is -- when you use the correct one. > 2. MSYS should not undef WIN32 Yes, it should undef WIN32. We *want* to use the msys facilities, just like the cygwin build uses the cygwin ones. We're not trying to build a native win32 perl here. > For 5.6 I added arpa/inet.h, sys/socket.h and all win32.h headers to > the CORE dir. URK. It sounds like you've been "doing it wrong" for a long time. That seems to be a very odd way of building native win32 extensions with an MSYS perl...I'm surprised that ever worked. > Furthermore gcc/mingw32/4.5.2 does not look like to have sigjmp_buf, > only typedef int jmp_buf[16]; > So I undef'd /*#define HAS_SIGSETJMP / **/ also > > Then it compiles, but I got two missing syms: > C.o:C.c:(.text+0x55): undefined reference to `_imp__PL_sys_intern' > C.o:C.c:(.text+0x7c): undefined reference to `_imp__win32_async_check' See above. Try again, but enter CPAN from an MSYSDVLPR shell instead. (And make sure that you have: msys-gcc-bin msys-binutils-bin msys-w32api-dev installed -- you'll get them via mingw-get install msys-system-builder -- Chuck |