Re: 2 MinGW-related feature requests.
- Original Message - From: "Jan Dubois" > However, when you have C:\MinGW\bin in your PATH, then it would add > C:\MinGW\lib, which is where all the libfoo.a import libraries for the > standard Windows libraries are stored. Adding this directory gets rid of > these warnings: > > Note (probably harmless): No library found for -lkernel32 > Note (probably harmless): No library found for -luser32 > Note (probably harmless): No library found for -lgdi32 > Note (probably harmless): No library found for -lwinspool > Note (probably harmless): No library found for -lcomdlg32 > Note (probably harmless): No library found for -ladvapi32 > Note (probably harmless): No library found for -lshell32 . . > Note (probably harmless): No library found for -lmsvcrt > > At least for modules using Module::Install, like Par-Packer. The > warnings are harmless, but it seems better to suppress them than > to confuse a user that something might be wrong when actually it > isn't. I see - I think that's a good enough reason to be doing this. > I guess I'll need to add some more code to ActivePerl::Config > to replace Perl\site\lib with Perl\site\lib\auto\MinGW\lib. > > So any objections to appending that location to LIBRARY_PATH? None. > PS: MinGW-5.1.4.1 seems to be on the external PPM servers now >if you want to give it a try. > Thanks - I'll have a play with it later tonight. Cheers, Rob ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
RE: 2 MinGW-related feature requests.
On Mon, 13 Jul 2009, Sisyphus wrote:
> From: "Jan Dubois"
> > 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:
>
> Again, I've struck no need to remove the additional 2 lines that you
> have, but again, the application of that patch doesn't break anything.
> I don't know why $ENV{ACTIVEPERL_MINGW}/lib was being pushed onto
> @libpath in the first place. For me, that resolves to my perl/site/lib
> directory and there's certainly no reason for me to push that location
> onto @libpath. Did it ever serve a purpose for anyone ?
Good point; the code is actually broken when you invoke gcc via the
forwarders in Perl\site\bin.
However, when you have C:\MinGW\bin in your PATH, then it would add
C:\MinGW\lib, which is where all the libfoo.a import libraries for the
standard Windows libraries are stored. Adding this directory gets rid of
these warnings:
Note (probably harmless): No library found for -lkernel32
Note (probably harmless): No library found for -luser32
Note (probably harmless): No library found for -lgdi32
Note (probably harmless): No library found for -lwinspool
Note (probably harmless): No library found for -lcomdlg32
Note (probably harmless): No library found for -ladvapi32
Note (probably harmless): No library found for -lshell32
Note (probably harmless): No library found for -lole32
Note (probably harmless): No library found for -loleaut32
Note (probably harmless): No library found for -lnetapi32
Note (probably harmless): No library found for -luuid
Note (probably harmless): No library found for -lws2_32
Note (probably harmless): No library found for -lmpr
Note (probably harmless): No library found for -lwinmm
Note (probably harmless): No library found for -lversion
Note (probably harmless): No library found for -lodbc32
Note (probably harmless): No library found for -lodbccp32
Note (probably harmless): No library found for -lmsvcrt
At least for modules using Module::Install, like Par-Packer. The
warnings are harmless, but it seems better to suppress them than
to confuse a user that something might be wrong when actually it
isn't.
I guess I'll need to add some more code to ActivePerl::Config
to replace Perl\site\lib with Perl\site\lib\auto\MinGW\lib.
So any objections to appending that location to LIBRARY_PATH?
Cheers,
-Jan
PS: MinGW-5.1.4.1 seems to be on the external PPM servers now
if you want to give it a try.
___
Perl-Win32-Users mailing list
Perl-Win32-Users@listserv.ActiveState.com
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
Re: 2 MinGW-related feature requests.
- Original Message -
From: "Jan Dubois"
> 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".
I don't really have much input into MinGW (lack of tuits), but I do post
there occasionally, and am still subscribed to the users list. I'll raise
this with them and give you a brief summary of their position on this.
> 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.
I'll download it in a day or two, and check that it's fine. (I'm sure it
will be.)
> 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");
>
I haven't struck a need to make the above amendment - but I've just tested
it now and the application of that patch doesn't seem to break anything.
> --- 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)){
Again, I've struck no need to remove the additional 2 lines that you have,
but again, the application of that patch doesn't break anything.
I don't know why $ENV{ACTIVEPERL_MINGW}/lib was being pushed onto @libpath
in the first place. For me, that resolves to my perl/site/lib directory and
there's certainly no reason for me to push that location onto @libpath. Did
it ever serve a purpose for anyone ?
> 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?
For me, there's no problem with that - as I said above, it's merely my
perl/site/lib folder that's being added to the end of LIBRARY_PATH, and that
folder doesn't contain any libraries.
Afaict, it's also not true that "GCC will already have this location built
in" ... I'm starting to think there's some code there that hasn't been doing
anything useful at all, and that it's still there only because it hasn't
actually caused anything to break.
> 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.
Shall do, when time permits. (Bit rushed tonight - but I wanted to get a
reply back :-)
Thanks again, Jan.
Cheers,
Rob
___
Perl-Win32-Users mailing list
Perl-Win32-Users@listserv.ActiveState.com
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
RE: 2 MinGW-related feature requests.
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.pmSun 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
Re: 2 MinGW-related feature requests.
- Original Message - From: "Jan Dubois" To: "'Sisyphus'" ; "'perl-win32-users'" Sent: Monday, July 13, 2009 4:07 AM Subject: RE: 2 MinGW-related feature requests. > On Sun, 12 Jul 2009, Sisyphus wrote: >> >> Should I submit the 2 proposals below to bugzilla ? > > Yes, please! > Done. Thanks Jan. Cheers, Rob ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
RE: 2 MinGW-related feature requests.
On Sun, 12 Jul 2009, Sisyphus wrote:
>
> Should I submit the 2 proposals below to bugzilla ?
Yes, please!
> 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 ?
Note that all the *.exe files are all the same. You can just copy any of
them to windres.exe in the same directory to get another forwarder.
Which is all those executables do: they take their commandline and
replace the actual executable name with something that redirects to
../lib/auto/MinGW/bin/ and then re-execs themselves. The only exception is
if the name is dmake.exe, in which case it gets redirected to
../lib/auto/dmake/ instead.
The only reason the forwarders exists is to keep the relative directory
structure of the MinGW install intact *and* be able to let PPM install
and remove it. Which means it can only install into the site/bin and
site/lib trees.
> 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};
> }
Yes, sounds like a good idea to me too. Will add it to ActivePerl,
but please file a bug to make sure it doesn't get lost.
> I've been using this in my own builds of perl for quite some time, and
> it's a very handy amendment to have in place. (Amending Kid.pm by hand
> every time I update EU::MM/perl does, however, become rather
> tiresome.) I asked Schwern to put it in the official release of
> EU::MM, but he refused - worried it might break something. It then
> occurred to me that, since ActivePerl ships with ActiveState's own
> version of EU::MM, ActiveState might be willing to include that code.
>
> (Better still if someone can convince Schwern to stick it in the
> official release.)
Yes, I would like to be able to get all the ActivePerl modifications
into the CPAN version of ExtUtils::MakeMaker, but it is not easy to
generalize them enough to make them useful outside ActivePerl.
And Schwern just pulled the HTML generation extensions from the CPAN
version *again* because there was some problem with it.
Anyways, I hope I'll get around to it eventually, but in the meantime
we can stick the MinGW stuff into ActivePerl at least.
Cheers,
-Jan
___
Perl-Win32-Users mailing list
Perl-Win32-Users@listserv.ActiveState.com
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
2 MinGW-related feature requests.
Hi,
Should I submit the 2 proposals below to bugzilla ?
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 ?
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 been using this in my own builds of perl for quite some time, and it's
a very handy
amendment to have in place. (Amending Kid.pm by hand every time I update
EU::MM/perl does,
however, become rather tiresome.) I asked Schwern to put it in the official
release of EU::MM,
but he refused - worried it might break something. It then occurred to me
that, since ActivePerl
ships with ActiveState's own version of EU::MM, ActiveState might be willing
to include that
code. (Better still if someone can convince Schwern to stick it in the
official release.)
Cheers,
Rob
___
Perl-Win32-Users mailing list
Perl-Win32-Users@listserv.ActiveState.com
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
