Beefy Boxes and Bandwidth Generously Provided by pair Networks
Think about Loose Coupling

Module::Install hacking

by syphilis (Chancellor)
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:


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.


Replies are listed 'Best First'.
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.

        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 --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.


Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://993090]
Approved by stevieb
Front-paged by ww
[dazz]: At present, I am saving the Image::Grab image to disk, then creating a new Image::Magick object that reads the disk file.
[dazz]: .
[choroba]: Discipulus Sounds interesting. Any pictures of the puppets or paintings?

How do I use this? | Other CB clients
Other Users?
Others surveying the Monastery: (9)
As of 2017-03-27 07:44 GMT
Find Nodes?
    Voting Booth?
    Should Pluto Get Its Planethood Back?

    Results (317 votes). Check out past polls.