Beefy Boxes and Bandwidth Generously Provided by pair Networks
good chemistry is complicated,
and a little bit messy -LW
 
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 lurking in the Monastery: (12)
As of 2014-11-27 17:18 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    My preferred Perl binaries come from:














    Results (186 votes), past polls