Skip Menu |

This queue is for tickets about the PAR-Packer CPAN distribution.

Report information
The Basics
Id: 30181
Status: open
Priority: 0/
Queue: PAR-Packer
People
Owner: Nobody in particular
Requestors: BMORROW [...] cpan.org
Cc:
AdminCc:
Bug Information
Severity: Normal
Broken in: 0.976
Fixed in: (no value)

History Show all quoted text
  Sun Oct 21 16:36:31 2007 BMORROW [...] cpan.org - Ticket created
Subject: Incompatibility with SVN on Win32
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
  Wed Apr 22 15:24:17 2009 puetzk [...] puetzk.org - Correspondence added
On Sun Oct 21 16:36:31 2007, BMORROW wrote: Show quoted text
> 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.
Index: PAR/Heavy.pm =================================================================== --- PAR.orig/Heavy.pm 2009-04-14 18:40:26.478976500 -0500 +++ PAR/Heavy.pm 2009-04-14 18:43:42.629643900 -0500 @@ -86,7 +86,10 @@ $member = PAR::_find_par_any(undef, $file, 1) if defined &PAR::_find_par_any; return $bootstrap->(@args) unless $member; # we failed to find the dll, let DynaLoader (try or) throw an error - $FullCache{$file} = _dl_extract($member, $file); + my $name = $member->fileName; + $name =~ s{.*/}{}; + + $FullCache{$file} = _dl_extract($member, $file, $name); # Now extract all associated shared objs in the same auto/ dir # XXX: shouldn't this also set $FullCache{...} for those files?
  Wed Apr 22 15:24:18 2009 The RT System itself - Status changed from 'new' to 'open'