Wed Apr 22 15:24:17 2009: Request 30181 was acted upon.
Transaction: Correspondence added by puetzk
Queue: PAR-Packer
Subject: Incompatibility with SVN on Win32
Broken in: 0.976
Severity: Normal
Owner: Nobody
Requestors: [email protected]
Status: new
Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=30181 >On Sun Oct 21 16:36:31 2007, BMORROW wrote: > Under WinXP, with either AS Perl 5.8.8.822 or Strawberry Perl > 5.8.8-alpha-2 and the SVN 1.4.5 libs from subversion.tigris.org, the exe > created by > > pp -o svn.exe -e "use SVN::Client; my $x = SVN::Client->new" > > will not run. Initially it fails because it cannot find _Core.dll; this > is because the SVN extension dlls all link to _Core.dll, so it has to be > locatable by name. Copying _Core.dll to the current directory fixes > this, but then it crashes somewhere inside libapr. AFAICT, it's crashing > in apr_palloc at line 606 of apr\memory\unix\apr_pools.c, but I'm not > really familiar with cdb and I don't have Visual Studio on this machine. > This crash does not occur simply by running the oneliner above, and it > does not occur on FreeBSD. > > Ben The crash is because your fix gives you two copies of _Core.dll, (one loaded by the Win32 linker from _Core.dll, one loaded by Dynaloader with a mangled name) which don't share global variables the way SVN expects them to (calls that initialized something via Core.pm don't affect the copy of _Core that Client.dll is using). I've attached a patch I use to PAR::Heavy that disables name mangling for when extracting DLLs for Dynaloader. This has potential problems of its own (you could get collisions between different modules) but it fixes SVN. The right fix is probably to recreate the original lib/auto/Foo/Foo.dll structure, but I didn't get that ambitious when I hit the problem.
PAR-no-namemangling.patch
Description: Binary data
