Beefy Boxes and Bandwidth Generously Provided by pair Networks
Welcome to the Monastery
 
PerlMonks  

Re^2: Module::Install hacking

by syphilis (Canon)
on Sep 12, 2012 at 03:30 UTC ( #993130=note: print w/ replies, xml ) Need Help??


in reply to Re: Module::Install hacking
in thread Module::Install hacking

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


Comment on Re^2: Module::Install hacking
Download Code
Re^3: Module::Install hacking
by syphilis (Canon) on Sep 14, 2012 at 03:42 UTC
    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

        Thanks for running the check !!

        But where does the site/bin directory come from?

        For my AS build of perl-5.14, I have:
        C:\>perl -V:installsitebin installsitebin='C:\_32\ap1400\site\bin'; C:\>perl -V:installsitescript installsitescript='C:\_32\ap1400\site\bin'; C:\>perl -V:sitebin sitebin='C:\_32\ap1400\site\bin'; C:\>perl -V:sitebinexp sitebinexp='C:\_32\ap1400\site\bin'; C:\>
        So, if perl/site/bin is not there from the start, I guess it gets created whenever a module wants to install something into either installsitebin, installsitescript, sitebin, or sitebinexp.
        I expect that ppm will install anything that's cound in blib/script into whatever is specified by $Config{installsitescript}.

        Bit of a pity that the AS builds specify that config setting. (My MinGW build specifies nothing for installsitescript, and specifies perl/bin for installsitebin.)

        Cheers,
        Rob

      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

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

        Hmmm ... so I just need to figure out a way of clobbering installsitebin ...
        ;-))))

        Cheers,
        Rob
      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?
        (details of which are not posted in this thread)

        Not many details to report - it was just one of those "perl.exe has stopped working" type of messages as the program (ie any program that had loaded Gtk2-WebKit) was exiting.
        I don't know the exact details of what was going wrong, but both libgcc_sis_452.dll and libgcc_s_dw2-1.dll (which were identical) had been loaded by different parts of the program. Restructuring so that libgcc_sis_452.dll was used throughout fixed the problem.

        My guess is that, during exit of "the program", a handle was being thrown to the wrong dll.

        NOTE: The 2 dlls were not actually identical, but were close enough to identical. I did replace libgcc_s_dw2-1.dll with a copy that *was* identical to libgcc_sis_452.dll and it made no difference.

        Cheers,
        Rob

Log In?
Username:
Password:

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

How do I use this? | Other CB clients
Other Users?
Others rifling through the Monastery: (6)
As of 2014-09-15 10:10 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    My favorite cookbook is:










    Results (146 votes), past polls