Net::LDAP makefile generation fails on ActiveState Perl 5.8.8

[Clyde Ingram]

I install ActiveState 5.8.8 on 2 PCs (one running Windows NT4 SP6, the other
running Windows XP SP2).
In both cases, the "perl Makefile.PL" command fails like this:

D:\Drivers\Perl\CPAN\Net-LDAP-Bundle\perl-ldap-0.33>perl Makefile.PL
Undefined subroutine &ActivePerl::Config::find_prog called at
E:/Perl/site/lib/ActivePerl/Config.pm line 70.
Compilation failed in require at E:/Perl/lib/ExtUtils/MakeMaker.pm line 7.
BEGIN failed--compilation aborted at E:/Perl/lib/ExtUtils/MakeMaker.pm line
7.
Compilation failed in require at inc/Module/Install/Can.pm -
/Users/gbarr/Library/Perl/Module/Install/Can.pm line 8.
BEGIN failed--compilation aborted at inc/Module/Install/Can.pm -
/Users/gbarr/Library/Perl/Module/Install/Can.pm line 8.
Compilation failed in require at inc/Module/Install.pm -
/Users/gbarr/Library/Perl/Module/Install.pm line 267.
Global symbol "$Verbose" requires explicit package name at
E:/Perl/lib/ExtUtils/MM_Any.pm line 1267.
Global symbol "$Verbose" requires explicit package name at
E:/Perl/lib/ExtUtils/MM_Any.pm line 1277.
Compilation failed in require at E:/Perl/lib/ExtUtils/MM_Unix.pm line 25.
Compilation failed in require at inc/Module/Install/Metadata.pm -
/Users/gbarr/Library/Perl/Module/Install/Metadata.pm line 173.
D:\Drivers\Perl\CPAN\Net-LDAP-Bundle\perl-ldap-0.33>

That initial "Undefined subroutine" error is odd, because the subroutine
"find_prog" is defined in Path.pm.
The module Config.pm includes:

package ActivePerl::Config;
....
use ActiveState::Path qw(find_prog realpath);
use Config ();
....
if ($^O eq "MSWin32" && !find_prog(_orig_conf("cc"))) {


Now, module E:/Perl/site/lib/ActiveState/Path.pm includes:

package ActiveState::Path;
....
our @EXPORT_OK = qw(path_list find_prog is_abs_path abs_path join_path
rel_path unsymlinked realpath);
....
sub find_prog {

So why is the subroutine reported as being undefined?
Note that installing with PPM avoids this problem. However, my target
machines are not connected to the Internet, so PPM/Internet is not an option
in my production environment.

Thank-you for constructive advice,
Clyde

[Sisyphus]

"Clyde Ingram"
<clydenospamorham@nospamorhamgetofftheline.freeser venospamorham.co.uk> wrote
in message news:7hMmg.5007$1g.3598@newsfe1-win.ntli.net...

> I install ActiveState 5.8.8 on 2 PCs (one running Windows NT4 SP6, the

other

> running Windows XP SP2).
> In both cases, the "perl Makefile.PL" command fails like this:
>
> D:\Drivers\Perl\CPAN\Net-LDAP-Bundle\perl-ldap-0.33>perl Makefile.PL
> Undefined subroutine &ActivePerl::Config::find_prog called at
> E:/Perl/site/lib/ActivePerl/Config.pm line 70.

It's a problem with Module::Install and ActivePerl - see the thread "PAR
problems" at [url]http://www.mail-archive.com/par@perl.org/[/url]. Within that thread,
the post (from Jan Dubois) at
[url]http://www.mail-archive.com/par@perl.org/msg02184.html[/url] is probably the most
relevant:

-- quote --
"You need to use Module::Install 0.61 to properly work with
ActivePerl::Config:

[url]http://rt.cpan.org/Public/Bug/Display.html?id=18181[/url]


Or just remove this line from your current Module::Install to check if
updating
Module::Install will fix the PAR issue:

local @INC = ($path, @INC);"
-- end quote --

Although that advice is aimed at getting PAR to build, it should work with
ActiveState perl for *any* Makefile.PL that wants to 'use
inc::Module::Install'.

Cheers,
Rob

[harryfmudd [AT] comcast [DOT] net]

Clyde Ingram wrote:

<snip />

> Note that installing with PPM avoids this problem. However, my target
> machines are not connected to the Internet, so PPM/Internet is not an option
> in my production environment.
>

So why not just set up your own PPM repository where your production
machines can see it? Create a directory somewhere, get the zip files
from ActiveState, and expand them into your directory.

From this point, I know that creating a virtual directory in (e.g.) IIS
gets you an http repository, referred to by [url]http://your_server/your_dir/[/url].

It has been a while since I have messed with file: based repositories,
but I doubt it's any more complicated. But in my case it was easier to
convince the security people to punch a hole in an internal firewall for
port 80 than it was to get the holes to make UNC file access work.

Tom Wyant

[David WE Roberts]

On Fri, 23 Jun 2006 12:57:01 -0400, harryfmudd [AT] comcast [DOT] net
wrote:

> Clyde Ingram wrote:
>
> <snip />
>

>> Note that installing with PPM avoids this problem. However, my target
>> machines are not connected to the Internet, so PPM/Internet is not an option
>> in my production environment.
>>

>
> So why not just set up your own PPM repository where your production
> machines can see it? Create a directory somewhere, get the zip files
> from ActiveState, and expand them into your directory.
>
> From this point, I know that creating a virtual directory in (e.g.) IIS
> gets you an http repository, referred to by [url]http://your_server/your_dir/[/url].
>
> It has been a while since I have messed with file: based repositories,
> but I doubt it's any more complicated. But in my case it was easier to
> convince the security people to punch a hole in an internal firewall for
> port 80 than it was to get the holes to make UNC file access work.
>
> Tom Wyant

Sounds easy and sensible; it almost is :-(

For some obscure reason:
the ZIP files available from the ActiveState site are version numbered
the 'tar.gz' files within the ZIP are version numbered
the 'ppd' files within the ZIP are NOT version numbered.

e.g.
ABI.zip contains
ABI.ppd
ABI.tar.gz

ABI-0.01.zip contains
ABI.ppd
ABI-0.01.tar.gz

Because both versions have the same name for the 'ppd' file you can't
just download all the ZIP files then unzip them to create your repository.
[Been there, done that, no T shirt]

I ended up having to write a Perl ditty to unzip each archive to a work
area and rename the 'ppd' file to match the 'zip' file name before adding
it to the repository.

Oh, and I had to get '7-zip' to be able to unzip from the command line.

All in all, what should have been a download and a quick unzip turned into
a major exercise.

I still have **NO IDEA** why the 'ppd' files are not version numbered.

Ho hum.

Dave R

P.S. three of the '.ppd' files had XML problems which prevented the
'search' command in 'ppm' from working. I had to rename them to
'.ppd.broken' to have a full working repository.

[harryfmudd [AT] comcast [DOT] net]

David WE Roberts wrote:

> On Fri, 23 Jun 2006 12:57:01 -0400, harryfmudd [AT] comcast [DOT] net
> wrote:
>
>

>>Clyde Ingram wrote:
>>
>><snip />
>>

>>>Note that installing with PPM avoids this problem. However, my target
>>>machines are not connected to the Internet, so PPM/Internet is not an option
>>>in my production environment.
>>>

>>
>>So why not just set up your own PPM repository where your production
>>machines can see it? Create a directory somewhere, get the zip files
>>from ActiveState, and expand them into your directory.
>>
>> From this point, I know that creating a virtual directory in (e.g.) IIS
>>gets you an http repository, referred to by [url]http://your_server/your_dir/[/url].
>>
>>It has been a while since I have messed with file: based repositories,
>>but I doubt it's any more complicated. But in my case it was easier to
>>convince the security people to punch a hole in an internal firewall for
>>port 80 than it was to get the holes to make UNC file access work.
>>
>>Tom Wyant

>
>
> Sounds easy and sensible; it almost is :-(
>
> For some obscure reason:
> the ZIP files available from the ActiveState site are version numbered
> the 'tar.gz' files within the ZIP are version numbered
> the 'ppd' files within the ZIP are NOT version numbered.
>
> e.g.
> ABI.zip contains
> ABI.ppd
> ABI.tar.gz
>
> ABI-0.01.zip contains
> ABI.ppd
> ABI-0.01.tar.gz
>
> Because both versions have the same name for the 'ppd' file you can't
> just download all the ZIP files then unzip them to create your repository.
> [Been there, done that, no T shirt]
>
> I ended up having to write a Perl ditty to unzip each archive to a work
> area and rename the 'ppd' file to match the 'zip' file name before adding
> it to the repository.
>
> Oh, and I had to get '7-zip' to be able to unzip from the command line.
>
> All in all, what should have been a download and a quick unzip turned into
> a major exercise.
>
> I still have **NO IDEA** why the 'ppd' files are not version numbered.
>
> Ho hum.
>
> Dave R
>
> P.S. three of the '.ppd' files had XML problems which prevented the
> 'search' command in 'ppm' from working. I had to rename them to
> '.ppd.broken' to have a full working repository.
>

Hmm. Well, it _used_ to be easy and simple. Guess someone decided to
"fix" it.

Sorry for the wild goose chase.

Tom Wyant

[Sisyphus]

"David WE Roberts"
..
..

>
> I still have **NO IDEA** why the 'ppd' files are not version numbered.
>

Basically it's because there's generally no need to do so. I can see that in
your case, where (for some reason) you're wanting to extract ABI-0.01.zip
and ABI-0.02.zip to the same location, that there's a need to uniquely
identify the 'ABI.ppd' files - and that versioning the ppd files would
satisfy that requirement.

If you did the same thing with the CPAN source distro's you would have a
similar complaint to make - ie extract 'ABI-0.01.tar.gz' and
'ABI-0.02.tar.gz' to the same location and you would be saying "I still have
**NO IDEA** why the 'Makefile.PL' files are not version numbered" ... and I
would be saying "basically it's because there's generally no need to do so"
:-)

Cheers,
Rob