Beefy Boxes and Bandwidth Generously Provided by pair Networks
more useful options
 
PerlMonks  

Re: Module::Install hacking

by Anonymous Monk
on Sep 12, 2012 at 01:26 UTC ( #993106=note: print w/ replies, xml ) Need Help??


in reply to Module::Install hacking

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 :)


Comment on Re: Module::Install hacking
Select or Download Code
Re^2: Module::Install hacking
by syphilis (Canon) on Sep 12, 2012 at 03:30 UTC
    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
        If you've a mind to check that it works ok for you,

        With the addition of site/bin to my path, it does:

        C:\>perl -MGtk2::WebKit -E"say $Gtk2::WebKit::VERSION; <>; print $]" & + echo %errorlevel% 0.09 5.014002255 C:\>

        But where does the site/bin directory come from? It's not a part of the standard perl distribution; nor the ActiveState distributions.


        With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
        Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
        "Science is about questioning the status quo. Questioning authority".
        In the absence of evidence, opinion is indistinguishable from prejudice.

        RIP Neil Armstrong

        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 ?

        Nope, there is no folder in blib that decides if something goes under site

        perl -V:install.*

        If there is no -V:installsitebin it ends up in -V:installbin

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


        I guess because of the crash that BrowserUk identified (details of which are not posted in this thread), the question of ABI comes up. I dont have copy of libgcc_s_dw2-1.dll in my Strawberry Perl folder, but I found libgcc_s_sjlj-1.dll. I think it is identical to libgcc_s_dw2-1.dll. Here are its exports. Looks like it implements non-CPU-native math, and it implements GCC's C++ compliant exception handling. AFAIK, GCC's exception handling is not SEH/MS compliant. Note, I dont know the details on the post preprocessor or asm level of GCC exception handling. The question is, will the 2 different libgcc DLLs every try to pass a struct to each other, or use the same TLS slot, use the same Kernel32 Event, or see each other, or not see each other, for example, this line is MS DLL dependent, it lives in libgcc http://opensource.apple.com/source/llvmgcc42/llvmgcc42-2335.9/gcc/config/i386/cygming-crtbegin.c?

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://993106]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others drinking their drinks and smoking their pipes about the Monastery: (8)
As of 2014-12-29 10:24 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    Is guessing a good strategy for surviving in the IT business?





    Results (186 votes), past polls