Click here to get back home

Net::LDAP makefile generation fails on ActiveState Perl 5.8.8

 HomeNewsGroups | Search | About
 comp.lang.perl.modules    Post an article   get this group's latest topics as an RSS feed add this group's latest topics to your My MSN content add this group's latest topics to your My Yahoo content
Subject Author Date
Net::LDAP makefile generation fails on ActiveState Perl 5.8.8 Clyde Ingram 06-23-2006
Posted by Clyde Ingram on June 23, 2006, 2:57 am
Please log in for more thread options


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



Posted by Sisyphus on June 23, 2006, 5:20 am
Please log in for more thread options



"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.

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

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

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


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



Posted by harryfmudd [AT] comcast [DOT] on June 23, 2006, 12:57 pm
Please log in for more thread options


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 http://your_server/your_dir/.

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

Posted by David WE Roberts on July 5, 2006, 5:57 am
Please log in for more thread options


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 http://your_server/your_dir/.
>
> 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.


Posted by harryfmudd [AT] comcast [DOT] on July 5, 2006, 9:28 pm
Please log in for more thread options


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 http://your_server/your_dir/.
>>
>>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

Similar ThreadsPosted
Issues Installing CPAN Modules on Win NT - Activestate Perl 5.61 November 19, 2004, 6:52 am
HTML::Mason, mod_perl on Win32 w/ActiveState Perl December 21, 2004, 11:46 pm
RFC: SOAP module with implicit WSDL generation April 4, 2008, 2:38 pm
Perl/Tk build fails on HP-UX February 27, 2006, 4:58 pm
Perl Tk:Scheduler command called subroutine fails to talk to tk widgets January 31, 2007, 2:05 pm
Understaing NET::LDAP August 4, 2004, 10:47 am
Installation LDAP April 29, 2005, 6:27 am
async Net::LDAP October 10, 2005, 9:06 pm
Net::LDAP::Entry help... September 25, 2006, 10:11 pm
NET:LDAP start_tls does not work July 7, 2004, 12:19 pm

Our other projects:

Art Dolls, Fairies and Mermaids - Sunnyfaces.net

Roy's Linux, Programming and Search Engines messages

1-Script XML SitemapXML Sitemap