On Sun, 12 Jul 2009, Sisyphus wrote:
> 
> 1) I've found that we can't actually build perl using the MinGW that
>    gets installed using ppm. This happens because windres.exe cannot
>    be found. Adding the perl/site/lib/auto/MinGW folder fixes the
>    problem, but perhaps it would be better to put an executable named
>    windres.exe in perl/site/bin - as has been done for ar, g77, g++,
>    gcc and dlltool. Btw, what does the source code for those
>    executables look like ?

I've built a new MinGW package 5.1.4.1 for PPM that includes the forwarder
for windres.exe.

I found a somewhat surprising WTF in the MinGW installer itself: even though
the version number is unchanged at 5.1.4 the following 3 included packages
have been updated from the last time I downloaded it:

  from: binutils-2.17.50-20060824-1.tar.gz
    to: binutils-2.19.1-mingw32-bin.tar.gz

  from: mingwrt-3.15.1-mingw32.tar.gz
    to: mingwrt-3.15.2-mingw32-dev.tar.gz

  from: w32api-3.12-mingw32-dev.tar.gz
    to: w32api-3.13-mingw32-dev.tar.gz

If you have any contact with the MinGW developers you may want to mention
that updating the version number of MinGW might be a good idea.  I would
have expected that at least the "Build" number would be changed in the
mingw.ini file, but even that remained at "11".

The 5.1.4.1 PPM package will have all the "latest" bits, so you may want
to give it a spin.  It may take a day or two before it becomes visible on
the external PPM server.

> 2) ExtUtils::Liblist::Kid.pm contains the following:
> 
>     if ($VC and exists $ENV{LIB} and $ENV{LIB}) {
>         push @libpath, split /;/, $ENV{LIB};
>     }
> 
> It would be really neat if the same could be done for MinGW, by adding
> the following code immediately after the above code:
> 
>     # For the benefit of MinGW:
>     if ($GC and exists $ENV{LIBRARY_PATH} and $ENV{LIBRARY_PATH}) {
>         push @libpath, split /;/, $ENV{LIBRARY_PATH};
>     }

I've added that code, and also tried to use it for the ActivePerl::Config
hack that tells ExtUtils::Liblist::Kids about the MinGW library location:

--- lib/ActivePerl/Config.pm.~1~        Sun Jul 12 23:50:01 2009
+++ lib/ActivePerl/Config.pm    Sun Jul 12 23:50:01 2009
@@ -86,7 +86,15 @@
                # assume MinGW or similar is available
                $gcc =~ s,\\,/,g;
                my($mingw) = $gcc =~ m,^(.*)/bin/gcc\.exe$,;
-               $ENV{ACTIVEPERL_MINGW} = $mingw if defined $mingw;
+               if (defined $mingw) {
+                   $mingw .= "/lib";
+                   if (defined $ENV{LIBRARY_PATH}) {
+                       $ENV{LIBRARY_PATH} .= ";$mingw";
+                   }
+                   else {
+                       $ENV{LIBRARY_PATH} = $mingw;
+                   }
+               }
 
                _override("cc", "gcc");
                _override("ccname", "gcc");

--- lib/ExtUtils/Liblist/Kid.pm.~1~     Sun Jul 12 23:50:01 2009
+++ lib/ExtUtils/Liblist/Kid.pm Sun Jul 12 23:50:01 2009
@@ -272,8 +272,8 @@
     if ($VC and exists $ENV{LIB} and $ENV{LIB}) {
         push @libpath, split /;/, $ENV{LIB};
     }
-    if ($GC and exists $ENV{ACTIVEPERL_MINGW} and $ENV{ACTIVEPERL_MINGW}) {
-        push @libpath, "$ENV{ACTIVEPERL_MINGW}/lib";
+    if ($GC and exists $ENV{LIBRARY_PATH} and $ENV{LIBRARY_PATH}) {
+        push @libpath, split /;/, $ENV{LIBRARY_PATH};
     }
 
     foreach (Text::ParseWords::quotewords('\s+', 0, $potential_libs)){

This should make it easier to eventually get the changes back into the CPAN
version.  Do you see any problem with pushing the MinGW/lib directory to
the end of LIBRARY_PATH even though GCC will already have this location
built in?  I'll do some testing before the next release myself, but feel
free to try it and see if you find any problems with this.

Cheers,
-Jan

_______________________________________________
Perl-Win32-Users mailing list
Perl-Win32-Users@listserv.ActiveState.com
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs

Reply via email to