Beefy Boxes and Bandwidth Generously Provided by pair Networks
laziness, impatience, and hubris
 
PerlMonks  

Re^3: Module::Install hacking

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


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

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


Comment on Re^3: Module::Install hacking
Download Code
Re^4: Module::Install hacking
by BrowserUk (Pope) on Sep 14, 2012 at 04:34 UTC
    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
        I expect that ppm will install anything that's cound in blib/script into whatever is specified by $Config{installsitescript}.

        All well and good, but as it never gets added to the path, it will always require manual intervention for anything that uses it, to work.

        I'll say this once and forever hold my peace on it, but your whole renaming dlls, sticking them in a "common place", and using --force to install them is fundamentally flawed.

        What happens when one of your renamed dlls changes? You have just recreated the whole msvcrt.dll dll-hell scenario over again.

        I install two of your packages each has a dependency upon a different version of one or more of your renamed dlls. Whichever order I install them in, one of them gets the wrong thing.

        And if I install some other package that uses the same dll, but under its real name, what then? If I use both modules in the same script, then I'm going to be using 2 different versions of the same code...

        MS (belatedly) got around to solving the problem when they implemented side-by-side assemblies.

        From the point of view of someone who will not have to go through the work of changing everything, and with a less than strong attitude toward properness, I think that you should be either:

        1. shipping these dlls under their real names, with each package that uses them, and place them in the same directory as the dll(s) that use them -- probably site\lib\auto\Package\Name\Name.dll.

          That way, when the day comes that one of your packages needs a later version of one of your renamed-to-sis dlls, its installation won't break every previous one still using the older version. And even if one script uses two packages that each depend upon a different versions, everything will still work because of the side-by-side feature.

        2. At a stretch, if the multiple copies of the same thing issue really offends you, then create a separate package -- say MinGW::Redist -- and make it a dependency of all the other packages. It would need a perl component that caused the dlls to be loaded (from its site\lib\auto\MinGW\Redist\ path), but that could be as simple as:
          package MinGW::Redist; use Win32; Win32::LoadLibrary( 'libgcc_s_dw2_1.dll' ) or die $^E; Win32::LoadLibrary( 'libstdc++-6.dll' ) or die $^E; ... 1;

        The latter would avoid the need for --force, but would not resolve the problem of different packages needing different versions.

        Overall, the former is both the simplest and best solution.


        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

Re^4: Module::Install hacking
by Anonymous Monk on Sep 14, 2012 at 04:41 UTC

    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
Re^4: Module::Install hacking
by bulk88 (Priest) on Sep 14, 2012 at 19:51 UTC
    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
        Not many details to report

        The guts of the problem was an unhandled exception during the cleanup of g++ exception stack frames. Beyond that I did not have the appropriate MinGW symbol files to trace into.


        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

Log In?
Username:
Password:

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

How do I use this? | Other CB clients
Other Users?
Others cooling their heels in the Monastery: (12)
As of 2014-09-03 08:48 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    My favorite cookbook is:










    Results (35 votes), past polls