----- Original Message ----- From: "Ari Jolma" <[EMAIL PROTECTED]> To: <perl-win32-users@listserv.ActiveState.com> Sent: Friday, June 09, 2006 3:55 AM Subject: Issues in using a MinGW build
> Hi, I sent this to the perl-win32-porters list but that seems abandoned, > Yes - not much activity there. I'm still subscribed and I did see your original post. I thought there were some curious and interesting things - but didn't respond as I felt I didn't have anything greatly constructive to say - and I'm not all that interested in Gtk2. (Perhaps there were others who saw your post and decided to *not* respond for similar reasons.) > I recently compiled and used Perl in a MinGW (not MSYS) environment. The > compilation and installation was relatively straight-forward using these > instructions: http://www.adp-gmbh.ch/blog/2004/october/9.html > Those instructions look fine to me - pretty much the same advice as you get in Readme.win32 (in the perl source). I generally rename 'Makefile' to 'Makefile.nmake', so I don't have to bother with the '-f makefile.mk' stuff - but that's quite insignificant. > I then used the installation for compiling and installing a number of > Perl modules, including Gtk2. My notes are here: > http://map.hut.fi/PerlForGeoinformatics/Install.MinGW the main points are: > > * I fixed the file Config_heavy.pl in the Perl distribution to use > -shared instead of -mdll for lddlflags. I've built a large number of perl modules with my MinGW-built perl - some of which access external dll's - and I've never had to do that. I'm a little curious as to what it is about building Gtk2 that makes this necessary. In fact I wonder if it really *is* necessary. (However, I don't doubt that it fixed a problem for you :-) > > * I fixed the ExtUtils/Liblist/Kid.pm to recognize library names like > lib*.dll.a (the patch is at the above page) > I've always solved this problem by simply renaming lib*.dll.a to lib*.a - but your solution is quite acceptable (perhaps even more acceptable than mine.) > * I needed a parameter like dynamic_lib => > {OTHERLDFLAGS=>"-Wl,--out-implib=blib\\arch\\auto\\$lib\\lib$lib.dll.a > "}to WriteMakefile when the module contained a dll > > * the previous parameter makes gcc generate lib*.dll.a files into > arch/auto directory, they need to be used in linking, i.e., there must > be a corresponding -l*.dll in the LIBS if the module being compiled > contains a dll also > This, to me, was the most curious bit. Whenever you build a module that needs to be compiled you will end up with a dll in blib/arch/auto. But I've never found a 'dll.a' in blib/arch/auto - nor have I ever needed one. All I ever see is a '.packlist', a '.bs' and a '.dll' . Or were you referring to the case where the module references an external dll ? Again, even with those modules, I've never found or needed a 'lib*.dll.a'. Perhaps you've built your perl with options that I'm not familiar with - though the build instructions you gave in your link would seem to indicate your perl was built with the "usual" options. What does 'perl -V' report ? Incidentally, if you have built perl with the usual options then your Gtk2 binaries should work with ActiveState-built perl (or indeed any multithreaded Win32 perl). > * the Makefiles that are produced by Makefile.PL had to be repaired with > s/\{\{/\{/g; > I've never had to do that. Did you use the latest 'dmake' from http://search.cpan.org/dist/dmake/ ? > I'm not very knowledgeable about windows nor gcc, but the above things > seem to work. Maybe somebody more knowledgeable could comment? I'm using > Perl 5.8.8. > I'm using perl 5.8.8, too. I've probably had more experience with MinGW-built perl - but I'm just a hacker and certainly don't regard myself as all that knowledgeable. There were some things at http://map.hut.fi/PerlForGeoinformatics/Install.MinGW that also puzzled me (which I might as well mention while I'm at it). I was puzzled by: -- quote -- also make sure that you link to the dlls and not to the static libraries: LIBS => "-lgdal.dll" -- end quote -- That last line of the quote will, I believe, link to 'libgdal.dll.a' (or gdal.dll.a .... depending upon what it's called). If you wanted to link directly to the dll (which you can do with MinGW, but not Microsoft compilers) then I *think* you would use 'MYEXTLIB' rather than 'LIBS'. Secondly: -- quote -- perl Makefile.PL # don't worry about the "The system cannot find..." fixx.pl mingw32-make -- end quote -- Seemed odd to be invoking 'mingw32-make' instead of 'dmake' after having run 'perl Makefile.PL'. In fact, there were some earlier calls to 'mingw32-make' that also surprised me. If you're building in the MSYS shell you use 'make' not 'mingw32-make' - and if you're building a perl module you use 'dmake' not 'mingw32-make' ... I couldn't work out the circumstances that led you to using 'mingw32-make' (though I'm sure your reasons were valid ... or it wouldn't have worked :-) I think you've done well to build Gtk2 - and I don't see any problem with what you have done (which is why I didn't reply to your original post) - but there are the above things that puzzle me slightly (which is why I've succumbed to your second invitation to reply :-) There's really no need for you to respond to this - unless there's something there that you want to follow up - in which case I'm quite happy to continue the discussion. Even better if someone else chimes in with some thoughts - though I've not found there to be a lot of interest in MinGW on the perl-win32-users list ..... Cheers, Rob _______________________________________________ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
