CPAN - 'cl' is not recognized as an internal or external command,

[MoshiachNow]

HI,

when installing some modules - get an error:
'cl' is not recognized as an internal or external command,
operable program or batch file.
NMAKE : fatal error U1077: 'C:\WINDOWS\system32\cmd.exe' : return code
'0x1'
Stop.
NMAKE : fatal error U1077: 'C:\WINDOWS\system32\cmd.exe' : return code
'0x2'

I do not have an executable "cl.exe" anywhere on my machine.

Any advice?

Thanks

 

[Sisyphus]

HI,

when installing some modules - get an error:
'cl' is not recognized as an internal or external command,
operable program or batch file.
NMAKE : fatal error U1077: 'C:\WINDOWS\system32\cmd.exe' : return code
'0x1'
Stop.
NMAKE : fatal error U1077: 'C:\WINDOWS\system32\cmd.exe' : return code
'0x2'

I do not have an executable "cl.exe" anywhere on my machine.

Any advice?

Install such modules using the ppm utility instead.

Cheers,
Rob

 

[Mumia W.]

HI,

when installing some modules - get an error:
'cl' is not recognized as an internal or external command,
operable program or batch file.
NMAKE : fatal error U1077: 'C:\WINDOWS\system32\cmd.exe' : return code
'0x1'
[...]

You need a C compiler to install those modules.

 

[MoshiachNow]

You need a C compiler to install those modules.

Thanks.
No way to install it without a C compiler ?
Possibly using ppm,as suggested above ?

 

[MoshiachNow]

Install such modules using the ppm utility instead.

Thanks,Rob
Works like majic.

But why these errors pop up in the first place?
Do I realy need have C++ compilers installed for this ?

 

[Peter J. Holzer]

But why these errors pop up in the first place?

Because you tried to install modules (partially) written in C from
source code.

Do I realy need have C++ compilers installed for this ?

No, you don't need a C++ compiler. C++ is a different language than C.

You do need a C compiler if you want to compile modules written in C.

hp

 

[Mumia W.]

Thanks.
No way to install it without a C compiler ?
Possibly using ppm,as suggested above ?

I'm a Linux user The compiler is installed by default here.

Use Sisyphus' advice since you're on Windows.

 

[Henry McGuinness]

Ok you seem to be using ActivePerl for windows (you didn't say ). This is
compiled using Visual C++ version 6, and you have to use the same compiler
to build Perl modules that contain any functions written in C. Some modules
are Pure Perl, so you don't need to worry about compiling any C.

Not everyone is going to have VC++, so there are 2 approaches: By far the
easiest is to use PPM, which gives you compiled windows binaries (as .dll
files) for the relevant bits of the modules you want, and copies these and
the perl code to your perl/site/lib directory. Easy. And there are several
repositories with lots of modules on them, not all of the CPAN, though

More difficult is to build things with Active Perl if you haven't got VC++:
get hold of make.exe, cl.exe etc (you sometimes need a lot of libraries and
header files). Can be a painful way to go.

The Strawberry/Vanilla Perl projects are attempting to provide Windows Perl
distributions compiled using gcc (which is included in the distribution I
think) instead. So you'll be able to use CPAN. They're still experimental
though.

Henry

 

[Sisyphus]

Ok you seem to be using ActivePerl for windows (you didn't say ). This is
compiled using Visual C++ version 6, and you have to use the same compiler
to build Perl modules that contain any functions written in C.

That's not strictly true any more - though you won't go wrong if you follow
that advice.

Some time back ExtUtils::FakeConfig appeared, which enables you to use the
freely available MinGW (gcc) compiler with ActivePerl. It provides good
milage, too.

Then, starting with build 817 (I think), ActivePerl started working
seamlessly with the MinGW compiler (though ActivePerl is still built with
MSVC++6.0). They haven't got it quite right, however - and it doesn't
provide the milage you get with ExtUtils::FakeConfig. However, for many
extensions (modules), it works fine.

You can also generally use MSVC++ 7.0, 7.1, and 8.0 (which were/are freely
available)with ActivePerl. Again, there are exceptions.

So ... the waters have been muddied ... and I thought it simpler to tell the
op to "use ppm", rather than detail other options.

(The above info is provided as a "something you might find interesting",
rather than as a "correction"

Cheers,
Rob

 

[Henry McGuinness]

Ok you seem to be using ActivePerl for windows (you didn't say ). This is
compiled using Visual C++ version 6, and you have to use the same
compiler
to build Perl modules that contain any functions written in C.

That's not strictly true any more - though you won't go wrong if you
follow
that advice.

Some time back ExtUtils::FakeConfig appeared, which enables you to use the
freely available MinGW (gcc) compiler with ActivePerl. It provides good
milage, too.
[snip]

(The above info is provided as a "something you might find interesting",
rather than as a "correction"

Cheers,
Rob

Excellent. Many thanks. I'll look into that and try it out.

There were/are obviously complications with things like Inline, XS, and
compiling modules on Windows. Is there a site where all this info is covered
well? http://win32.perl.org is there but it seems a bit sparse so far.
Maybe I should write something on there (when I've done my research that
is!).

Henry

 

[Uri Guttman]

S> That's not strictly true any more - though you won't go wrong if you follow
S> that advice.

S> Some time back ExtUtils::FakeConfig appeared, which enables you to use the
S> freely available MinGW (gcc) compiler with ActivePerl. It provides good
S> milage, too.

S> Then, starting with build 817 (I think), ActivePerl started working
S> seamlessly with the MinGW compiler (though ActivePerl is still built with
S> MSVC++6.0). They haven't got it quite right, however - and it doesn't
S> provide the milage you get with ExtUtils::FakeConfig. However, for many
S> extensions (modules), it works fine.


and for the future there is a project going on called 'vanilla perl'
which will bundle a gcc build kit with a precompiled perl for
winblows. this will allow use of the cpan module and classic tarball
installation of any perl module, with or without xs/c. then the issue of
ppm modules being out of date will also go away (as soon as this gets
released and disseminated. like most winblows updates, who knows when it
will be downloaded? .

http://sourceforge.net/project/showfiles.php?group_id=158775
http://camelpack.sourceforge.net/index.php/VanillaPerl

maybe any of you would want to help with testing or whatever.

uri

 

[Sisyphus]

..
..

..
..

Excellent. Many thanks. I'll look into that and try it out.

EU::FC installs a fake config module (Config_m.pm) in Perl/site/lib.

It contains the line:
ld='gcc'

Best to change that to:
ld='g++'

When building perl modules you need to load those fake values, which you
achieve by running 'perl -MConfig_m Makefile.PL' instead of the more usual
'perl Makefile.PL'.
Sometimes (eg when building Inline::C ... I think) you need to set the
environment variable 'perl5opt' to '-MConfig_m'. That means that every time
the perl executable gets called, Config_m.pm is loaded. (Perhaps better to
simply set perl5opt and then unset it only if/when it causes a problem ...
not sure.) I haven't yet found a module that builds on MinGW-built perl but
fails to build on ActivePerl using Extutils::FakeConfig. The negative side
of EU::FC is the kludginess of having to invoke the '-MConfig_m' argument.

Uri mentioned 'vanilla perl' - also worth investigating.

Cheers,
Rob