Thread: [Module::Build] win32 install problem
Status: Beta
Brought to you by:
kwilliams
Menu
▾
▴
module-build-general
|
From: Ben L. <bla...@gm...> - 2006-05-12 15:04:15
|
Hi all, Module::Build won't install for me and I can't find anyone else on the net with my problem. My setup is XP SP 2. ------perl -v: This is perl, v5.6.1 built for MSWin32-x86-multi-thread (with 1 registered patch, see perl -V for more detail) Copyright 1987-2001, Larry Wall Binary build 635 based on sources provided by ActiveState Corp. http://www.ActiveState.com Built 21:04:21 Feb 25 2003 -----Error (perl Build.PL works fine): C:\Documents and Settings\Administrator\Desktop\firebird incoming\Module-Bu= ild-0 .28.tar\Module-Build-0.28>Build Use of uninitialized value in pattern match (m//) at c:/work/Perl/lib/File/= Spec/ Win32.pm line 72. Use of uninitialized value in pattern match (m//) at c:/work/Perl/lib/File/= Spec/ Win32.pm line 72. Use of uninitialized value in pattern match (m//) at c:/work/Perl/lib/File/= Spec/ Win32.pm line 140. mkdir blib\binhtml\bin\C:.: Invalid argument at lib/Module/Build/Base.pm li= ne 25 29 Any assistance would be appreciated! Please let me know if more information is required. Ben |
|
From: Ken W. <ke...@ma...> - 2006-05-12 17:06:59
|
Hi Ben, That looks to me like a File::Spec problem. Could you tell us what version of File::Spec you currently have installed? We may need to change the version we depend on for Win32 users. -Ken On May 12, 2006, at 9:35 AM, Ben Lavender wrote: > Hi all, > > Module::Build won't install for me and I can't find anyone else on the > net with my problem. > > My setup is XP SP 2. > ------perl -v: > > This is perl, v5.6.1 built for MSWin32-x86-multi-thread > (with 1 registered patch, see perl -V for more detail) > > Copyright 1987-2001, Larry Wall > > Binary build 635 based on sources provided by > ActiveState Corp. http://www.ActiveState.com > Built 21:04:21 Feb 25 2003 > > -----Error (perl Build.PL works fine): > C:\Documents and Settings\Administrator\Desktop\firebird incoming > \Module-Build-0 > .28.tar\Module-Build-0.28>Build > Use of uninitialized value in pattern match (m//) at c:/work/Perl/ > lib/File/Spec/ > Win32.pm line 72. > Use of uninitialized value in pattern match (m//) at c:/work/Perl/ > lib/File/Spec/ > Win32.pm line 72. > Use of uninitialized value in pattern match (m//) at c:/work/Perl/ > lib/File/Spec/ > Win32.pm line 140. > mkdir blib\binhtml\bin\C:.: Invalid argument at lib/Module/Build/ > Base.pm line 25 > 29 > > Any assistance would be appreciated! Please let me know if more > information is required. |
|
From: demerphq <dem...@gm...> - 2006-05-16 13:45:48
|
On 5/12/06, Ken Williams <ke...@ma...> wrote:
> Hi Ben,
>
> That looks to me like a File::Spec problem. Could you tell us what
> version of File::Spec you currently have installed? We may need to
> change the version we depend on for Win32 users.
Its not a version problem.
D:\home\.cpan5.8.x\build\PathTools-3.18>perl -MDDS -MFile::Spec
-e"Dump [File::Spec->splitdir('C:.\\')]"
$ARRAY1 =3D [
'C:.',
''
];
Its documented behaviour:
splitdir
The opposite of "catdir()".
@dirs =3D File::Spec->splitdir( $directories );
$directories must be only the directory portion of the path on systems
that have the concept of a volume or that have path syntax that
differentiates files from directories.
--=20
perl -Mre=3Ddebug -e "/just|another|perl|hacker/"
|
|
From: Randy W. S. <ml...@th...> - 2006-05-16 00:46:00
|
Ben Lavender wrote: > Hi all, > > Module::Build won't install for me and I can't find anyone else on the > net with my problem. > > My setup is XP SP 2. > ------perl -v: > > This is perl, v5.6.1 built for MSWin32-x86-multi-thread > (with 1 registered patch, see perl -V for more detail) > > Copyright 1987-2001, Larry Wall > > Binary build 635 based on sources provided by > ActiveState Corp. http://www.ActiveState.com > Built 21:04:21 Feb 25 2003 > > -----Error (perl Build.PL works fine): > C:\Documents and Settings\Administrator\Desktop\firebird > incoming\Module-Build-0 > .28.tar\Module-Build-0.28>Build > Use of uninitialized value in pattern match (m//) at > c:/work/Perl/lib/File/Spec/ > Win32.pm line 72. > Use of uninitialized value in pattern match (m//) at > c:/work/Perl/lib/File/Spec/ > Win32.pm line 72. > Use of uninitialized value in pattern match (m//) at > c:/work/Perl/lib/File/Spec/ > Win32.pm line 140. > mkdir blib\binhtml\bin\C:.: Invalid argument at lib/Module/Build/Base.pm > line 25 > 29 > > Any assistance would be appreciated! Please let me know if more > information is required. Sorry to take so long to look at this. I haven't yet been able to reproduce the problem. The problem seems to be that a directory name is getting corrupted somewhere. Eg. In this line from above: mkdir blib\binhtml\bin\C:.: Invalid argument at lib/Module/Build/Base.pm line 25 The trailing 'C:.' does not belong there. It'd be useful to see what values are in $path and @dirs if you are able to apply the following patch: --- Base.pm.orig 2006-04-28 00:14:03.000000000 -0400 +++ Base.pm 2006-05-15 20:37:05.796875000 -0400 @@ -2519,6 +2519,9 @@ my @dirs = File::Spec->splitdir( File::Spec->canonpath( $path ) ); pop( @dirs ) if $dirs[-1] eq File::Spec->curdir; +use Data::Dumper; warn Data::Dumper->Dump( [$name, $path, \@dirs], + [qw(name path dirs)] ); + my $fulldir = File::Spec->catfile($htmldir, @rootdirs, @dirs); my $outfile = File::Spec->catfile($fulldir, "${name}.html"); my $infile = File::Spec->abs2rel($pod); It'd also be useful to know if this happens in a directory without spaces, and if it happens after upgrading File::Spec[1] Regards, Randy. 1. <http://search.cpan.org/dist/PathTools/> |
|
From: Ben L. <bla...@gm...> - 2006-05-16 10:56:13
|
On 5/16/06, Randy W. Sims <ml...@th...> wrote: > Ben Lavender wrote: > > Hi all, > > > > Module::Build won't install for me and I can't find anyone else on the > > net with my problem. > > > > My setup is XP SP 2. > > ------perl -v: > > > > This is perl, v5.6.1 built for MSWin32-x86-multi-thread > > (with 1 registered patch, see perl -V for more detail) > > > > Copyright 1987-2001, Larry Wall > > > > Binary build 635 based on sources provided by > > ActiveState Corp. http://www.ActiveState.com > > Built 21:04:21 Feb 25 2003 > > > > -----Error (perl Build.PL works fine): > > C:\Documents and Settings\Administrator\Desktop\firebird > > incoming\Module-Build-0 > > .28.tar\Module-Build-0.28>Build > > Use of uninitialized value in pattern match (m//) at > > c:/work/Perl/lib/File/Spec/ > > Win32.pm line 72. > > Use of uninitialized value in pattern match (m//) at > > c:/work/Perl/lib/File/Spec/ > > Win32.pm line 72. > > Use of uninitialized value in pattern match (m//) at > > c:/work/Perl/lib/File/Spec/ > > Win32.pm line 140. > > mkdir blib\binhtml\bin\C:.: Invalid argument at lib/Module/Build/Base.p= m > > line 25 > > 29 > > > > Any assistance would be appreciated! Please let me know if more > > information is required. > > Sorry to take so long to look at this. I haven't yet been able to > reproduce the problem. The problem seems to be that a directory name is > getting corrupted somewhere. Eg. In this line from above: > > mkdir blib\binhtml\bin\C:.: > Invalid argument at lib/Module/Build/Base.pm line 25 > > The trailing 'C:.' does not belong there. > > It'd be useful to see what values are in $path and @dirs if you are able > to apply the following patch: > > --- Base.pm.orig 2006-04-28 00:14:03.000000000 -0400 > +++ Base.pm 2006-05-15 20:37:05.796875000 -0400 > @@ -2519,6 +2519,9 @@ > my @dirs =3D File::Spec->splitdir( File::Spec->canonpath( $path ) )= ; > pop( @dirs ) if $dirs[-1] eq File::Spec->curdir; > > +use Data::Dumper; warn Data::Dumper->Dump( [$name, $path, \@dirs], > + [qw(name path dirs)] ); > + > my $fulldir =3D File::Spec->catfile($htmldir, @rootdirs, @dirs); > my $outfile =3D File::Spec->catfile($fulldir, "${name}.html"); > my $infile =3D File::Spec->abs2rel($pod); > > > It'd also be useful to know if this happens in a directory without > spaces, and if it happens after upgrading File::Spec[1] The patch provides the same result, in directories both with and without sp= aces: $name =3D 'config_data'; $path =3D 'C:.\\'; $dirs =3D [ 'C:.' ]; A directory without spaces gives the same result. As before, upgrading File::Spec is something I might try and live without. I'd need to investigate what other multitude of packages I'm using might be affected by that upgrade; I'll try and do some of that today. > > Regards, > Randy. > > 1. <http://search.cpan.org/dist/PathTools/> > |
|
From: demerphq <dem...@gm...> - 2006-05-16 14:06:36
|
On 5/16/06, Ben Lavender <bla...@gm...> wrote:
> On 5/16/06, Randy W. Sims <ml...@th...> wrote:
> > Sorry to take so long to look at this. I haven't yet been able to
> > reproduce the problem. The problem seems to be that a directory name is
> > getting corrupted somewhere. Eg. In this line from above:
> >
> > mkdir blib\binhtml\bin\C:.:
> > Invalid argument at lib/Module/Build/Base.pm line 25
> >
> > The trailing 'C:.' does not belong there.
> >
> > It'd be useful to see what values are in $path and @dirs if you are abl=
e
> > to apply the following patch:
> >
> > --- Base.pm.orig 2006-04-28 00:14:03.000000000 -0400
> > +++ Base.pm 2006-05-15 20:37:05.796875000 -0400
> > @@ -2519,6 +2519,9 @@
> > my @dirs =3D File::Spec->splitdir( File::Spec->canonpath( $path )=
);
> > pop( @dirs ) if $dirs[-1] eq File::Spec->curdir;
...
> > It'd also be useful to know if this happens in a directory without
> > spaces, and if it happens after upgrading File::Spec[1]
>
> The patch provides the same result, in directories both with and without =
spaces:
>
> $name =3D 'config_data';
> $path =3D 'C:.\\';
> $dirs =3D [
> 'C:.'
> ];
>
> A directory without spaces gives the same result.
>
> As before, upgrading File::Spec is something I might try and live
> without. I'd need to investigate what other multitude of packages I'm
> using might be affected by that upgrade; I'll try and do some of that
> today.
Im pretty sure that the lines
my ($name, $path) =3D File::Basename::fileparse($pods->{$pod},
=09=09=09=09=09=09 qr{\.(?:pm|plx?|pod)$});
my @dirs =3D File::Spec->splitdir( File::Spec->canonpath( $path ) );
are wrong. FS->splitdir() splits a directory specification NOT a path.
If you use splitdir on a path that includes a volume specification
then obviously it wont work out (actually it will return the volume as
tho it was a directory)
I think you need something like:
my $spec=3DFile::Spec->canonpath( $pods->{$pod} );
my ($vol,$path,$file)=3D File::Spec->splitpath($spec);
my ($name) =3D File::Basename::fileparse($file,qr{\.(?:pm|plx?|pod)$});
my @dirs =3D File::Spec->splitdir( $path );
pop( @dirs ) if $dirs[-1] eq File::Spec->curdir;
Cheers,
Yves
--=20
perl -Mre=3Ddebug -e "/just|another|perl|hacker/"
|
|
From: Ken W. <ke...@ma...> - 2006-05-16 20:16:47
|
On May 16, 2006, at 7:40 AM, demerphq wrote:
> Im pretty sure that the lines
>
> my ($name, $path) = File::Basename::fileparse($pods->{$pod},
> qr{\.(?:pm|plx?|pod)$});
> my @dirs = File::Spec->splitdir( File::Spec->canonpath( $path ) );
>
> are wrong. FS->splitdir() splits a directory specification NOT a path.
> If you use splitdir on a path that includes a volume specification
> then obviously it wont work out (actually it will return the volume as
> tho it was a directory)
>
> I think you need something like:
>
> my $spec=File::Spec->canonpath( $pods->{$pod} );
> my ($vol,$path,$file)= File::Spec->splitpath($spec);
> my ($name) = File::Basename::fileparse($file,qr{\.(?:pm|plx?|pod)$});
> my @dirs = File::Spec->splitdir( $path );
> pop( @dirs ) if $dirs[-1] eq File::Spec->curdir;
Okay, does this patch rectify the situation?
-Ken
=== lib/Module/Build/Base.pm
==================================================================
--- lib/Module/Build/Base.pm (revision 1905)
+++ lib/Module/Build/Base.pm (local)
@@ -2523,7 +2523,8 @@
my ($name, $path) = File::Basename::fileparse($pods->{$pod},
qr{\.(?:pm|plx?|pod)$});
- my @dirs = File::Spec->splitdir( File::Spec->canonpath( $path ) );
+ my ($vol, $dirs) = File::Spec->splitpath($path, 1);
+ my @dirs = File::Spec->splitdir( File::Spec->canonpath( $dirs ) );
pop( @dirs ) if $dirs[-1] eq File::Spec->curdir;
my $fulldir = File::Spec->catfile($htmldir, @rootdirs, @dirs);
|
|
From: Randy W. S. <ra...@th...> - 2006-05-16 20:43:29
|
Ken Williams wrote:
>
> On May 16, 2006, at 7:40 AM, demerphq wrote:
>
>> Im pretty sure that the lines
>>
>> my ($name, $path) = File::Basename::fileparse($pods->{$pod},
>> qr{\.(?:pm|plx?|pod)$});
>> my @dirs = File::Spec->splitdir( File::Spec->canonpath( $path ) );
>>
>> are wrong. FS->splitdir() splits a directory specification NOT a path.
>> If you use splitdir on a path that includes a volume specification
>> then obviously it wont work out (actually it will return the volume as
>> tho it was a directory)
>>
>> I think you need something like:
>>
>> my $spec=File::Spec->canonpath( $pods->{$pod} );
>> my ($vol,$path,$file)= File::Spec->splitpath($spec);
>> my ($name) = File::Basename::fileparse($file,qr{\.(?:pm|plx?|pod)$});
>> my @dirs = File::Spec->splitdir( $path );
>> pop( @dirs ) if $dirs[-1] eq File::Spec->curdir;
>
> Okay, does this patch rectify the situation?
I can now reproduce this using AS perl 5.6 on Windows. The failure is in
->_find_pods at the call to abs2rel()
$files{$file} = File::Spec->abs2rel($file, $dir)
if $self->contains_pod( $file )
Here are some values as they are passed in and their results:
file => blib\lib
dir => blib\lib
result => C:
file => blib\lib/Simple.pm
dir => blib\lib
result => C:Simple.pm
file => blib\lib/Simple
dir => blib\lib
result => C:Simple
file => blib\lib/Simple/AllPod.pod
dir => blib\lib
result => C:Simple\AllPod.pod
file => blib\lib/Simple/NoPod.pm
dir => blib\lib
result => C:Simple\NoPod.pm
file => blib\arch
dir => blib\arch
result => C:
file => blib\lib
dir => blib\lib
result => C:
This is a bug in the version of File::Spec supplied, I think.
It still fails in the same way if I convert the paths to absolute paths
before the above call to abs2rel.
$file = File::Spec->rel2abs($file);
$dir = File::Spec->rel2abs($dir);
$files{$file} = File::Spec->abs2rel($file, $dir)
if $self->contains_pod( $file )
With:
file => C:\Downloads\Module-Build-0.28\t\_tmp\Simple\blib\lib\Simple.pm
dir => C:\Downloads\Module-Build-0.28\t\_tmp\Simple\blib\lib
result => C:Simple.pm
Is there a workaround or do we require an update File::Spec ???
Randy.
|
|
From: Ben L. <bla...@gm...> - 2006-05-16 22:46:16
|
The supplied patch gets me to perl Build test, which fails at this point:
t\runthrough......ok 13/28Use of uninitialized value in pattern match (m//)=
at c
:/work/Perl/lib/File/Spec/Win32.pm line 72.
Use of uninitialized value in pattern match (m//) at c:/work/Perl/lib/File/=
Spec/
Win32.pm line 72.
Use of uninitialized value in pattern match (m//) at c:/work/Perl/lib/File/=
Spec/
Win32.pm line 140.
t\runthrough......ok 19/28
t\runthrough......NOK 20# Failed test in t\runthrough.t at line 151.
# got: 'Can't locate object method "create_archive" via package "A=
rchiv
e::Tar" (perhaps you forgot to load "Archive::Tar"?) at C:\work\mbtest\Modu=
le-Bu
ild-0.28\blib\lib/Module/Build/Base.pm line 3436.
# '
# expected: ''
t\runthrough......ok 28/28# Looks like you failed 1 test of 28.
Archive::Tar isn't there because it's version .23 instead of 1.08 as
recommended/required. I tried installing that, but I managed to get
an entirely new and unrelated error, unrelated to this problem or this
mailing list (not my week!). I made sure to include those pattern
match errors because they get spewn out like carrots from a salad
shooter throughout all steps of the install and test process. It's
midnight for me and I'll try and bend Archive::Tar to my will tomorrow
and I'll make another run then.
For the record, I get this message while installing:
* Archive::Tar (0.23) is installed, but we prefer to have 1.08
I'm all for the softening of computer language to make it more user
friendly, but required is required and prefer is prefer :)
cheers, and thanks for all the help on this,
ben
On 5/16/06, Ken Williams <ke...@ma...> wrote:
>
> On May 16, 2006, at 7:40 AM, demerphq wrote:
>
> > Im pretty sure that the lines
> >
> > my ($name, $path) =3D File::Basename::fileparse($pods->{$pod},
> > qr{\.(?:pm|plx?|pod)$})=
;
> > my @dirs =3D File::Spec->splitdir( File::Spec->canonpath( $path ) );
> >
> > are wrong. FS->splitdir() splits a directory specification NOT a path.
> > If you use splitdir on a path that includes a volume specification
> > then obviously it wont work out (actually it will return the volume as
> > tho it was a directory)
> >
> > I think you need something like:
> >
> > my $spec=3DFile::Spec->canonpath( $pods->{$pod} );
> > my ($vol,$path,$file)=3D File::Spec->splitpath($spec);
> > my ($name) =3D File::Basename::fileparse($file,qr{\.(?:pm|plx?|pod)$})=
;
> > my @dirs =3D File::Spec->splitdir( $path );
> > pop( @dirs ) if $dirs[-1] eq File::Spec->curdir;
>
> Okay, does this patch rectify the situation?
>
> -Ken
>
> =3D=3D=3D lib/Module/Build/Base.pm
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> --- lib/Module/Build/Base.pm (revision 1905)
> +++ lib/Module/Build/Base.pm (local)
> @@ -2523,7 +2523,8 @@
> my ($name, $path) =3D File::Basename::fileparse($pods->{$pod},
> qr{\.(?:pm|plx?|pod)$})=
;
> - my @dirs =3D File::Spec->splitdir( File::Spec->canonpath( $path ) );
> + my ($vol, $dirs) =3D File::Spec->splitpath($path, 1);
> + my @dirs =3D File::Spec->splitdir( File::Spec->canonpath( $dirs ) );
> pop( @dirs ) if $dirs[-1] eq File::Spec->curdir;
> my $fulldir =3D File::Spec->catfile($htmldir, @rootdirs, @dirs);
>
>
|
|
From: Randy W. S. <ml...@th...> - 2006-05-17 04:12:44
|
Ben Lavender wrote:
> The supplied patch gets me to perl Build test, which fails at this point:
>
> t\runthrough......ok 13/28Use of uninitialized value in pattern match
> (m//) at c
> :/work/Perl/lib/File/Spec/Win32.pm line 72.
> Use of uninitialized value in pattern match (m//) at
> c:/work/Perl/lib/File/Spec/
> Win32.pm line 72.
> Use of uninitialized value in pattern match (m//) at
> c:/work/Perl/lib/File/Spec/
> Win32.pm line 140.
> t\runthrough......ok 19/28
> t\runthrough......NOK 20# Failed test in t\runthrough.t at line 151.
> # got: 'Can't locate object method "create_archive" via package
> "Archiv
> e::Tar" (perhaps you forgot to load "Archive::Tar"?) at
> C:\work\mbtest\Module-Bu
> ild-0.28\blib\lib/Module/Build/Base.pm line 3436.
> # '
> # expected: ''
> t\runthrough......ok 28/28# Looks like you failed 1 test of 28.
The patch works because it throws away the volume part, but the volume
shouldn't be there at all. All paths at this point should be relative,
which is why we could get away with a simple fileparse()
> Archive::Tar isn't there because it's version .23 instead of 1.08 as
> recommended/required. I tried installing that, but I managed to get
> an entirely new and unrelated error, unrelated to this problem or this
> mailing list (not my week!). I made sure to include those pattern
> match errors because they get spewn out like carrots from a salad
> shooter throughout all steps of the install and test process. It's
> midnight for me and I'll try and bend Archive::Tar to my will tomorrow
> and I'll make another run then.
>
> For the record, I get this message while installing:
> * Archive::Tar (0.23) is installed, but we prefer to have 1.08
> I'm all for the softening of computer language to make it more user
> friendly, but required is required and prefer is prefer :)
Not sure why the test in t/runthrough.t didn't detect the missing prereq...
SKIP: {
skip( "not sure if we can create a tarball on this platform", 1 )
unless $mb->check_installed_status('Archive::Tar', 0) ||
$mb->isa('Module::Build::Platform::Unix');
...
}
Unfortunately, I wont be able to look into this more until the weekend.
I'll be out of town from tomorrow morning until Friday evening.
Randy.
|
|
From: Ben L. <bla...@gm...> - 2006-05-18 17:12:32
|
> >
> > For the record, I get this message while installing:
> > * Archive::Tar (0.23) is installed, but we prefer to have 1.08
> > I'm all for the softening of computer language to make it more user
> > friendly, but required is required and prefer is prefer :)
>
> Not sure why the test in t/runthrough.t didn't detect the missing prereq...
>
> SKIP: {
> skip( "not sure if we can create a tarball on this platform", 1 )
> unless $mb->check_installed_status('Archive::Tar', 0) ||
> $mb->isa('Module::Build::Platform::Unix');
> ...
> }
>
> Unfortunately, I wont be able to look into this more until the weekend.
> I'll be out of town from tomorrow morning until Friday evening.
>
> Randy.
>
After banging my head at this all day, I'm stuck on it. ppm won't
upgrade Archive::Tar, and I can't make it install itself by any means
(nmake strikes again!). It seems I'm either stuck upgrading core bits
piecemeal or doing without. As mid-project is not the time for a
platform upgrade, I'm going to do without for now and install the
newest version of activestate in a few months, which includes a ppm
that can upgrade modules it uses itself and a newer version of
archive::tar to begin with.
I appreciate all the help on this, and I'll still run patches or
whatever if you guys want any more test cases, but I'm moving forward.
What I'm trying to say is: don't waste your 2 days of freedom on it
:)
cheers,
ben
|
|
From: Ron S. <ro...@sa...> - 2006-05-18 23:08:02
|
On Thu, 18 May 2006 19:12:24 +0200, Ben Lavender wrote:
Hi Ben
> After banging my head at this all day, I'm stuck on it. ppm won't
> upgrade Archive::Tar, and I can't make it install itself by any
> means (nmake strikes again!). It seems I'm either stuck upgrading
I don't know what you tried. Here's what I just did, using ppm V 2.1.6 &=
Perl V
5.8.7 from Randy Kobes at uwinnipeg:
o Manually delete Archive::Tar
o C:\Backup>ppm install --location=3Dhttp://theoryx5.uwinnipeg.ca/ppms
Archive::Tar
Can't locate Archive/Tar.pm in @INC (@INC contains: C:/Perl/lib=
C:/Perl/site/lib
.) at C:/Perl/site/
lib/PPM.pm line 28.
BEGIN failed--compilation aborted at C:/Perl/site/lib/PPM.pm line 28.
Compilation failed in require at C:\Perl\bin/ppm.bat line 21.
BEGIN failed--compilation aborted at C:\Perl\bin/ppm.bat line 21.
o Install local copy of V 1.29 'manually' (via a program actually)
o C:\Backup>ppm install --location=3Dhttp://theoryx5.uwinnipeg.ca/ppms
Archive::Tar
Version 0.072 of 'Archive-Tar' is already installed.
Remove it, or use 'verify --upgrade Archive-Tar'.
(This is because it's mentioned in C:\Perl\site\lib\ppm.xml)
C:\Backup>ppm verify --upgrade --location=3Dhttp://theoryx5.uwinnipeg.ca/ppms=
Archive::Tar
Duplicate POD found (shadowing?): Win32 (C:\Perl\lib/Win32.pod)
Already seen in C:\Perl\lib/Win32.pm
[Chop many more of same. How to I suppress this 'duplicate' stuff :-(?]
Bytes transferred: 37769
Installing C:\Perl\html\site\lib\Archive\Tar.html
Installing C:\Perl\html\site\lib\Archive\Tar\File.html
Installing C:\Perl\site\lib\Archive\Tar.pm
Installing C:\Perl\site\lib\Archive\Tar\Constant.pm
Installing C:\Perl\site\lib\Archive\Tar\File.pm
Installing C:\Perl\bin\ptardiff.bat
Installing C:\Perl\bin\ptar.bat
Installing C:\Perl\bin\ptardiff
Installing C:\Perl\bin\ptar
Writing C:\Perl\site\lib\auto\Archive\Tar\.packlist
Duplicate POD found (shadowing?): Win32 (C:\Perl\lib/Win32.pod)
Already seen in C:\Perl\lib/Win32.pm
[Chop may more of same]
Package 'Archive-Tar' is up to date.
--
Cheers
Ron Savage, ro...@sa... on 19/05/2006
http://savage.net.au/index.html
Let the record show: Microsoft is not an Australian company
|
|
From: Ben L. <bla...@gm...> - 2006-05-19 01:02:10
|
> I don't know what you tried. Here's what I just did, using ppm V 2.1.6 & Perl V > 5.8.7 from Randy Kobes at uwinnipeg: > I tried two things: Installing archive::tar manually, which died somehow with nmake; this is not uncommon for attempting to install packages on win32. As A::T wanted to use nmake, which often means a package wants to do something funky with its install, I didn't want to install it manually. ppm at version 2 doesn't much like to upgrade packages it uses, and when I renamed it as a test, ppm wouldn't start, as your example shows. A bit more funging didn't help any. As it turns out, though, installing it manually via copying from the tar.gz (ugh), as you suggest, did the trick just fine. M::B built, tested, installed and worked, and all was well on my little overly-paranoid development platform. This was using the patch supplied by Ken W. a few days ago. I'm continually astounded by the help I find on mailing lists for perl modules. Thanks to everyone for the extra help on this. Ben |
|
From: Ron S. <ro...@sa...> - 2006-05-19 08:43:33
|
On Fri, 19 May 2006 03:02:03 +0200, Ben Lavender wrote: Hi Ben > As it turns out, though, installing it manually via copying from > the tar.gz (ugh), as you suggest, did the trick just fine. M::B No, I did not suggest that. I suggested you could install it in the official= manner, so to speak, from Randy's site, or download it and install it like= any other module. I certainly like to see /exactly/ what was happening when it did not install= gor you. -- Cheers Ron Savage, ro...@sa... on 19/05/2006 http://savage.net.au/index.html Let the record show: Microsoft is not an Australian company |
|
From: Ben L. <bla...@gm...> - 2006-05-19 12:17:59
|
> > As it turns out, though, installing it manually via copying from > > the tar.gz (ugh), as you suggest, did the trick just fine. M::B > > No, I did not suggest that. I suggested you could install it in the official > manner, so to speak, from Randy's site, or download it and install it like any > other module. > > I certainly like to see /exactly/ what was happening when it did not install gor > you. With ppm version 2.1.6, I would attempt to install A::T. It was a very old version, and ppm would find an upgrade. Upon a verify --upgrade for AT, I'd get that the package was already up to date. Some web searching told me that many people have had similar problems with ppm version 2 (it seems version 3 is not so troublesome), as version 2 doesn't much like to upgrade packages it is using, and reporting that a package is already up to date is ppm2's backwards way of saying 'I can't do that'. There wasn't an accepted solution out there for dealing with it via ppm 2, I found cases 4 pages into google results of people who had to upgrade their AS installation entirely to get around the problem for an important module which required c compliation (details having since taken their leave of me). Installing AT from the tgz or via the CPAN module got me nowhere. Perl actually crashes halfway through the tests, suggesting I let Microsoft know about this problem. Along with this came an all-too-telling message, after reading previous messages on this thread, that long filename extraction support would be disabled. Whenever I removed AT manually, ppm wouldn't start, plain and simple. Putting it back fixed the problem. You said: o Install local copy of V 1.29 'manually' (via a program actually) which gave me the idea to just throw the .pm files in the correct location, which I did. I'm not sure what you did here, but after this, your ppm would run again. Mine ran again too, after I installed it manually, but even a forced verify upgrade gives me a reassuring message that AT is up to date, just as before, so I don't really see how to duplicate your behavior. Ben Ben |
|
From: Ken W. <ke...@ma...> - 2006-05-18 19:16:52
|
On May 16, 2006, at 11:12 PM, Randy W. Sims wrote:
> Ben Lavender wrote:
>> Archive::Tar isn't there because it's version .23 instead of 1.08 as
>> recommended/required. I tried installing that, but I managed to get
>> an entirely new and unrelated error, unrelated to this problem or
>> this
>> mailing list (not my week!). I made sure to include those pattern
>> match errors because they get spewn out like carrots from a salad
>> shooter throughout all steps of the install and test process. It's
>> midnight for me and I'll try and bend Archive::Tar to my will
>> tomorrow
>> and I'll make another run then.
>> For the record, I get this message while installing:
>> * Archive::Tar (0.23) is installed, but we prefer to have 1.08
>> I'm all for the softening of computer language to make it more user
>> friendly, but required is required and prefer is prefer :)
>
> Not sure why the test in t/runthrough.t didn't detect the missing
> prereq...
>
> SKIP: {
> skip( "not sure if we can create a tarball on this platform", 1 )
> unless $mb->check_installed_status('Archive::Tar', 0) ||
> $mb->isa('Module::Build::Platform::Unix');
> ...
> }
I think basically everything is working as designed - the reason we
"prefer" to have a newer version of Archive::Tar is that older
versions fail on some platforms, but we don't exactly know which
ones. In this case, we tell the user what version we have, what
version we think we *want* to have, and then we test things out to
see if it works.
That said, this probably isn't designed very well. =) For one thing,
many users never care about the ability to create tarballs, because
they only want to use M::B to install things, not to create
distributions. For another thing, it would be nice if we could just
identify the version of A::T we require, then list it as a dependency.
Unfortunately, on some platforms *no* version of A::T seems to work
properly (as far as I'm last aware - I may have fallen behind on the
issue), and its maintainers haven't been receptive to patches that
fix it. Also, on some platforms (Unix, cygwin, etc.) we'll pretty
much always have /usr/bin/tar around, so we don't really need *any*
version of A::T.
More than you wanted to know, I'm sure....
-Ken
|
|
From: demerphq <dem...@gm...> - 2006-05-19 07:35:10
|
On 5/18/06, Ken Williams <ke...@ma...> wrote: > Unfortunately, on some platforms *no* version of A::T seems to work > properly (as far as I'm last aware - I may have fallen behind on the > issue), and its maintainers haven't been receptive to patches that > fix it. Also, on some platforms (Unix, cygwin, etc.) we'll pretty > much always have /usr/bin/tar around, so we don't really need *any* > version of A::T. I supplied a patch to Archive::Tar which fixed it. Unfortunately the patch was rejected. At this point I think it was rejected for no reason, and I intend to follow up on the subject today. http://rt.cpan.org/Ticket/Display.html?id=18720#txn-186661 http://rt.cpan.org/Ticket/Display.html?id=18720#txn-191947 If it turns out that the basis of the rejection was incorrect I intend to give Jos a second chance to fix things himself. If he doesnt I intend to do something drastic, possibly going so far as to fork Archive::Tar. Anyway, use of a later Archive::Tar guarantees that the tar file you produce will not work with much of the free decompression software available on Win32. Jos decided to change the long file format handling sometime after he took of maint of Archive::Tar to POSIX style. This style is not well supported and has restrictive path length and file name length constriants. The old mechism used the Gnu Extended Header mechanism which has no upper limit on file or path length, and appears to be supported by most tar packages, certainly it is supported by GNU tar which should be widely available. Yves -- perl -Mre=debug -e "/just|another|perl|hacker/" |
|
From: Ron S. <ro...@sa...> - 2006-05-19 08:41:46
|
On Fri, 19 May 2006 09:28:58 +0200, demerphq wrote: Hi > software available on Win32. Jos decided to change the long file > format handling sometime after he took of maint of Archive::Tar to > POSIX style. This style is not well supported and has restrictive It'd be great if the output files didn't trigger the WinZip problem= mentioned here: http://savage.net.au/Perl-modules/html/installing-a-module.html oh so long ago :-(. -- Cheers Ron Savage, ro...@sa... on 19/05/2006 http://savage.net.au/index.html Let the record show: Microsoft is not an Australian company |
|
From: demerphq <dem...@gm...> - 2006-05-19 09:46:14
|
On 5/19/06, Ron Savage <ro...@sa...> wrote: > On Fri, 19 May 2006 09:28:58 +0200, demerphq wrote: > > Hi > > > software available on Win32. Jos decided to change the long file > > format handling sometime after he took of maint of Archive::Tar to > > POSIX style. This style is not well supported and has restrictive > > It'd be great if the output files didn't trigger the WinZip problem mentioned > here: > > http://savage.net.au/Perl-modules/html/installing-a-module.html > > oh so long ago :-(. That is exactly the problem my patch attempts to resolve. cheers, Yves -- perl -Mre=debug -e "/just|another|perl|hacker/" |
|
From: Ken W. <ke...@ma...> - 2006-05-19 12:31:39
|
On May 19, 2006, at 2:28 AM, demerphq wrote: > I supplied a patch to Archive::Tar which fixed it. Unfortunately the > patch was rejected. At this point I think it was rejected for no > reason, and I intend to follow up on the subject today. > > http://rt.cpan.org/Ticket/Display.html?id=18720#txn-186661 > http://rt.cpan.org/Ticket/Display.html?id=18720#txn-191947 > > If it turns out that the basis of the rejection was incorrect I intend > to give Jos a second chance to fix things himself. If he doesnt I > intend to do something drastic, possibly going so far as to fork > Archive::Tar. > > Anyway, use of a later Archive::Tar guarantees that the tar file you > produce will not work with much of the free decompression software > available on Win32. Eek. Well, god speed, man. I hope you can get things worked out, but I agree that this would be worth a fork & namechange if not. The whole point of the module is essentially broken now. -Ken |
|
From: Ken W. <ke...@ma...> - 2006-05-18 19:23:22
|
On May 16, 2006, at 11:12 PM, Randy W. Sims wrote: > Ben Lavender wrote: >> The supplied patch gets me to perl Build test, which fails at this >> point: >> t\runthrough......ok 13/28Use of uninitialized value in pattern >> match (m//) at c >> :/work/Perl/lib/File/Spec/Win32.pm line 72. >> Use of uninitialized value in pattern match (m//) at c:/work/Perl/ >> lib/File/Spec/ >> Win32.pm line 72. >> Use of uninitialized value in pattern match (m//) at c:/work/Perl/ >> lib/File/Spec/ >> Win32.pm line 140. >> t\runthrough......ok 19/28 >> t\runthrough......NOK 20# Failed test in t\runthrough.t at line >> 151. >> # got: 'Can't locate object method "create_archive" via >> package "Archiv >> e::Tar" (perhaps you forgot to load "Archive::Tar"?) at C:\work >> \mbtest\Module-Bu >> ild-0.28\blib\lib/Module/Build/Base.pm line 3436. >> # ' >> # expected: '' >> t\runthrough......ok 28/28# Looks like you failed 1 test of 28. > > The patch works because it throws away the volume part, but the > volume shouldn't be there at all. Yeah, it shouldn't, but there it is. =) Older versions of File::Spec include it, and even though it's not strictly incorrect to have a drive letter on a relative path, if we don't jump through the byzantine File::Spec hoops correctly we'll screw things up. Newer versions of File::Spec don't include the drive letter in this situation - there are some regression tests in File::Spec now to ensure that. -Ken |
|
From: Randy W. S. <ml...@th...> - 2006-06-06 02:44:19
Attachments:
mb.diff
|
Ken Williams wrote: > > On May 16, 2006, at 11:12 PM, Randy W. Sims wrote: > >> Ben Lavender wrote: >>> The supplied patch gets me to perl Build test, which fails at this >>> point: >>> t\runthrough......ok 13/28Use of uninitialized value in pattern match >>> (m//) at c >>> :/work/Perl/lib/File/Spec/Win32.pm line 72. >>> Use of uninitialized value in pattern match (m//) at >>> c:/work/Perl/lib/File/Spec/ >>> Win32.pm line 72. >>> Use of uninitialized value in pattern match (m//) at >>> c:/work/Perl/lib/File/Spec/ >>> Win32.pm line 140. >>> t\runthrough......ok 19/28 >>> t\runthrough......NOK 20# Failed test in t\runthrough.t at line 151. >>> # got: 'Can't locate object method "create_archive" via >>> package "Archiv >>> e::Tar" (perhaps you forgot to load "Archive::Tar"?) at >>> C:\work\mbtest\Module-Bu >>> ild-0.28\blib\lib/Module/Build/Base.pm line 3436. >>> # ' >>> # expected: '' >>> t\runthrough......ok 28/28# Looks like you failed 1 test of 28. >> >> The patch works because it throws away the volume part, but the volume >> shouldn't be there at all. > > Yeah, it shouldn't, but there it is. =) Older versions of File::Spec > include it, and even though it's not strictly incorrect to have a drive > letter on a relative path, if we don't jump through the byzantine > File::Spec hoops correctly we'll screw things up. > > Newer versions of File::Spec don't include the drive letter in this > situation - there are some regression tests in File::Spec now to ensure > that. File::Spec 0.84 seems to work ok. I'd recommend bumping the prereq. Otherwise, the attached patch allows it to work with 0.82. Randy. |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X