Beefy Boxes and Bandwidth Generously Provided by pair Networks
Just another Perl shrine
 
PerlMonks  

Module::Install hacking

by syphilis (Canon)
on Sep 12, 2012 at 00:21 UTC ( #993090=perlquestion: print w/ replies, xml ) Need Help??
syphilis has asked for the wisdom of the Perl Monks concerning the following question:

Hi,

The building of the Gtk2-WebKit module is handled by inc/Module::Install. When I build Gtk2-WebKit on Windows, I get the following output:
... [ XS xs\WebKit.xs ] [ CC xs\WebKit.c ] [ XS xs\WebKitDownload.xs ] [ CC xs\WebKitDownload.c ] [ XS xs\WebKitWebView.xs ] ... [ CC xs\WebKitWebView.c ] [ XS xs\WebKitWebWindowFeatures.xs ] [ CC xs\WebKitWebWindowFeatures.c ] ...
But the actual compilation command (that compiles the .c files into .o files) is not made visible.
How do I change that ?
I really would like to see that these .c files are being compiled with -mms-bitfields (which is in $Config{ccflags}), as I suspect they are not.

Cheers,
Rob

Comment on Module::Install hacking
Select or Download Code
Re: Module::Install hacking
by Anonymous Monk on Sep 12, 2012 at 01:26 UTC

    How do I change that ?

    Maybe  "perl Makefile.PL verbose" , maybe  dmake VERBOSE=9999 or  dmake -v

    If there was a self-contained xs based module that used M::I I would try it :)

      Yep - dmake -v is all it takes. Thanks.

      Of course, in the meantime I'd figured out that -mms-bitfields would probably *not* be the cause of my problems, as the crash I get (on ActivePerl only) happens at cleanup - whereas the absence of -mms-bitfields will cause problems much earlier than that.

      So now I just need to figure out why my mingw-built binaries work fine on mingw-built perl, but crash on exit when run on ActivePerl.

      Cheers,
      Rob
        So now I just need to figure out why my mingw-built binaries work fine on mingw-built perl, but crash on exit when run on ActivePerl

        BrowserUk established that the crash was occurring in the libgcc_s_dw2-1.dll ... and that piece of information made the job of fixing the problem so much easier.

        Most of my ppm packages have a dependency on libgcc_s_dw2-1.dll, so I therefore distribute that file with them.
        But rather than have ppm install individual copies of that dll for each module that needs it, I usually just place it in blib/script (for all module packages, whether they need it or not) - so that it gets installed into either perl/bin or perl/site/bin. That way the user only ever has the one copy of that file installed.
        It's not a large file, so packaging it with every ppm is not terribly wasteful. For that matter, it probably wouldn't matter if each module *did* have its own copy of libgcc_s_dw2-1.dll ... but that doesn't fit too well with *my* idea of tidiness.

        However, I don't like the idea of installing that dll into a path folder (which is where it needs to go) - given that there could well be other instances of that dll elsewhere in the path, thereby causing some incompatibility.
        So, I rename a copy of libgcc_s_dw2-1.dll to libgcc_sis_452.dll, have the module look for that dll instead, and distribute (in blib/script of the ppm package) libgcc_sis_452.dll instead of libgcc_s_dw2-1.dll. (I also take a similar approach with libstdc++-6.dll which I've renamed to cpp+-6_sis.dll, but I distribute that file only with the few packages that actually need it.)

        One drawback with that is that, having 'ppm install'ed one of my packages, you then need to use '--force' with future 'ppm installs' of any other of my packages - otherwise the installation fails because ppm won't overwrite a file (namely, perl/site/bin/libgcc_sis_452.dll) that was installed by another ppm package.

        So ... getting back to the cause of the crash ... I knew that there was no problem with libgcc_s_dw2-1.dll, because I had been using and distributing it (albeit under a different name) for quite some time ... yet, here it was, causing a problem.
        I think this happened because *both* libgcc_sis_452.dll and libgcc_s_dw2-1.dll were being loaded by the application. In effect, the same dll was being loaded *twice*.

        Restructuring the building of Gtk2-WebKit-0.09 such that there's no dependency on any dll named libgcc_s_dw2-1.dll fixes the problem for me.

        Thanks yet again, Buk. If you've a mind to check that it works ok for you, just

        ppm install http://www.sisyphusion.tk/ppm/Gtk2-WebKit.ppd --force

        and add perl/site/bin to your path.
        It's a bit annoying that Perl/site/bin doesn't get added to the path by default ... I wonder if there's a folder in the blib where I can place libgcc_sis_452.dll in order that it will invariably end up in perl/bin ?

        And thanks to Hans Oesterholt, who prodded me into getting this done - and even located the requisite (pre-built) libraries for me.

        Cheers,
        Rob

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://993090]
Approved by stevieb
Front-paged by ww
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others meditating upon the Monastery: (9)
As of 2015-07-07 08:51 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    The top three priorities of my open tasks are (in descending order of likelihood to be worked on) ...









    Results (88 votes), past polls