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

Discussion in 'Perl Misc' started by MoshiachNow, Sep 4, 2006.

  1. MoshiachNow

    MoshiachNow Guest

    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
     
    MoshiachNow, Sep 4, 2006
    #1
    1. Advertisements

  2. MoshiachNow

    Sisyphus Guest

    Install such modules using the ppm utility instead.

    Cheers,
    Rob
     
    Sisyphus, Sep 4, 2006
    #2
    1. Advertisements

  3. MoshiachNow

    Mumia W. Guest

    You need a C compiler to install those modules.
     
    Mumia W., Sep 4, 2006
    #3
  4. MoshiachNow

    MoshiachNow Guest

    Thanks.
    No way to install it without a C compiler ?
    Possibly using ppm,as suggested above ?
     
    MoshiachNow, Sep 4, 2006
    #4
  5. MoshiachNow

    MoshiachNow Guest

    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 ?
     
    MoshiachNow, Sep 4, 2006
    #5
  6. Because you tried to install modules (partially) written in C from
    source code.
    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
     
    Peter J. Holzer, Sep 4, 2006
    #6
  7. MoshiachNow

    Mumia W. Guest

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

    Use Sisyphus' advice since you're on Windows.
     
    Mumia W., Sep 4, 2006
    #7
  8. 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
     
    Henry McGuinness, Sep 5, 2006
    #8
  9. MoshiachNow

    Sisyphus Guest

    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
     
    Sisyphus, Sep 5, 2006
    #9
  10. 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
     
    Henry McGuinness, Sep 5, 2006
    #10
  11. MoshiachNow

    Uri Guttman Guest

    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
     
    Uri Guttman, Sep 5, 2006
    #11
  12. MoshiachNow

    Sisyphus Guest

    ..
    ..
    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
     
    Sisyphus, Sep 6, 2006
    #12
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.