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