dmake.exe: Error: -- 'C:\Perl\libConfig.pm' not found, and can't bemade

[tuser1]

I am trying to build Scalar::Util::Refcount from CPAN on Windows XP
under Activestate 5.10

C:\>perl -v
This is perl, v5.10.0 built for MSWin32-x86-multi-thread
(with 5 registered patches, see perl -V for more detail)

Copyright 1987-2007, Larry Wall

Binary build 1004 [287188] provided by ActiveState http://www.ActiveState.com
Built Sep 3 2008 13:16:37
===========================

I have downloaded and extracted Scalar::Util::Refcount from CPAN and I
have successfully installed MinGW.ppm from http://ppm4.activestate.com/MSWin32-x86/5.10/1004/,

but when I try to run dmake to make , it fails...

C:\Scalar-Util-Refcount-1.0.2>dmake
dmake.exe: Error: -- `C:\Perl\libConfig.pm' not found, and can't be
made

 

[sisyphus]

dmake.exe:  Error: -- `C:\Perl\libConfig.pm' not found

What does 'dmake -V' output ?

With my build of 1004 (where I *don't* have the problem you've
reported) it outputs:

#########################
dmake.exe - Version 4.11-20080107-SHAY (Windows / MS Visual C++)
Copyright (c) 1990,...,1997 by WTI Corp.

Default Configuration:
MAXLINELENGTH := 32766
MAXPROCESSLIMIT := 4
MAXPROCESS := 1
.IMPORT .IGNORE: DMAKEROOT
.MAKEFILES : makefile.mk makefile
.SOURCE : .NULL
DMAKEROOT *= $(ABSMAKECMD:d)startup
MAKESTARTUP := $(DMAKEROOT)\startup.mk

Please read the NEWS file for the latest release notes.
#########################

Is there anything at http://www.perlmonks.org/index.pl?node_id=603230
that helps ? (If so, what ? It would be nice to get to the bottom of
this error once and for all

Cheers,
Rob

 

[tuser1]

What does 'dmake -V' output ?

With my build of 1004 (where I *don't* have the problem you've
reported) it outputs:

#########################
dmake.exe - Version 4.11-20080107-SHAY (Windows / MS Visual C++)
Copyright (c) 1990,...,1997 by WTI Corp.

Default Configuration:
        MAXLINELENGTH := 32766
        MAXPROCESSLIMIT := 4
        MAXPROCESS := 1
        .IMPORT .IGNORE: DMAKEROOT
        .MAKEFILES : makefile.mk makefile
        .SOURCE    : .NULL
        DMAKEROOT *= $(ABSMAKECMD:d)startup
        MAKESTARTUP := $(DMAKEROOT)\startup.mk

Please read the NEWS file for the latest release notes.
#########################

Is there anything athttp://www.perlmonks.org/index.pl?node_id=603230
that helps ? (If so, what ? It would be nice to get to the bottom of
this error once and for all

Here is my output from "dmake -V", looks identical to yours:
===========================
C:\>dmake -V
dmake.exe - Version 4.11-20080107-SHAY (Windows / MS Visual C++)
Copyright (c) 1990,...,1997 by WTI Corp.

Default Configuration:
MAXLINELENGTH := 32766
MAXPROCESSLIMIT := 4
MAXPROCESS := 1
.IMPORT .IGNORE: DMAKEROOT
.MAKEFILES : makefile.mk makefile
.SOURCE : .NULL
DMAKEROOT *= $(ABSMAKECMD:d)startup
MAKESTARTUP := $(DMAKEROOT)\startup.mk

Please read the NEWS file for the latest release notes.
===========================

According to the article on Perlmonks, here is my output for
ExtUtils::MakeMaker and the contents of the Makefile:
===========================
C:\>perl -MExtUtils::MakeMaker -e "print
$ExtUtils::MakeMaker::VERSION"
Set up gcc environment - 3.4.5 (mingw-vista special r3)
6.42_01

contents of Makefile:
[...]
AR_STATIC_ARGS = cr
DIRFILESEP = ^\
DFSEP = $(DIRFILESEP)
[...]
===========================

I then intervened manually in the Makefile and changed

DIRFILESEP = ^\

into

DIRFILESEP = \\

....but now I have a different error message
===========================
C:\Scalar-Util-Refcount-1.0.2>dmake
dmake.exe: Error executing 'rem': No such file or directory
dmake.exe: Error code 255, while making 'blibdirs'
===========================

 

[sisyphus]

On Apr 19, 12:27 am, sisyphus <[email protected]> wrote:

I then intervened manually in the Makefile and changed

DIRFILESEP = ^\

into

DIRFILESEP = \\

It's really strange that DIRFILESEP is set to ^\ for you. For me it's
definitely set to \\.
Yet we both have the same build of ActivePerl, the same version of
EU::MM (I also have 6.42_01), the same version of dmake, and the same
MinGW compiler. I wonder what it is that makes the difference.

Did you install ActivePerl from the zip package or the msi package ? I
don't know why that should matter ... just clutching at straws
(I installed from the zip package, btw.)

...but now I have a different error message
===========================
C:\Scalar-Util-Refcount-1.0.2>dmake
dmake.exe:  Error executing 'rem': No such file or directory
dmake.exe:  Error code 255, while making 'blibdirs'

Don't think I've seen that error before.
Could you email me the Makefile ? - to sisyphus1 at (@) optusnet dot
(.) com dot(.) au. (Or post it to some public location where we can
all access it. I suspect it's bad etiquette to post a file of that
size to this newsgroup, though I could be wrong about that.)
I think it would help if we could do a 'diff -u' between the Makefile
you get, and the Makefile I get.

The Makefile I get can be seen at http://www.perlmonks.org/index.pl?viewmode=public;node_id=587490
for anyone interested.

Cheers,
Rob

 

[tuser1]

Don't think I've seen that error before.
Could you email me the Makefile ? - to sisyphus1 at (@) optusnet dot
(.) com dot(.) au. (Or post it to some public location where we can
all access it. I suspect it's bad etiquette to post a file of that
size to this newsgroup, though I could be wrong about that.)
I think it would help if we could do a 'diff -u' between the Makefile
you get, and the Makefile I get.

The Makefile I get can be seen athttp://www.perlmonks.org/index.pl?viewmode=public;node_id=587490
for anyone interested.

I have upgraded EU::MM from version 6.42_01 to version 6.50 (about one
hour ago), but this shouldn't make any difference though, as the
problem still persists in exactly the same manner.

The makefile (for Scalar::Util::Refcount version 1.0.2) is too big to
be posted on c.l.p.m., therefore I had to send it to you per e-mail.

I hope the 'diff -u' between our two Makefiles is not too big, so it
can be posted on c.l.p.m

b.t.w., I have installed Activestate using the .msi package.

 

[tuser1]

I have upgraded EU::MM from version 6.42_01 to version 6.50 (about one
hour ago), but this shouldn't make any difference though, as the
problem still persists in exactly the same manner.

The makefile (for Scalar::Util::Refcount version 1.0.2) is too big to
be posted on c.l.p.m., therefore I had to send it to you per e-mail.

I hope the 'diff -u' between our two Makefiles is not too big, so it
can be posted on c.l.p.m

b.t.w., I have installed Activestate using the .msi package.

one additional thing:
many years ago, I installed "nmake" of the Visual C++ compiler suite,
maybe something tells EU::MM that it has to use "nmake" (and not
"dmake")

for example in ExtUtils\MM_Win32.pm:
[...]
sub init_DIRFILESEP {
my($self) = shift;

# The ^ makes sure its not interpreted as an escape in nmake
$self->{DIRFILESEP} = $self->is_make_type('nmake') ? '^\\' :
$self->is_make_type('dmake') ? '\\\\'
: '\\';
}

However, I have checked my environment variables, but I could not find
anything related to "make", "dmake" or "nmake"

 

[tuser1]

I have upgraded EU::MM from version 6.42_01 to version 6.50 (about one
hour ago), but this shouldn't make any difference though, as the
problem still persists in exactly the same manner.

The makefile (for Scalar::Util::Refcount version 1.0.2) is too big to
be posted on c.l.p.m., therefore I had to send it to you per e-mail.

I hope the 'diff -u' between our two Makefiles is not too big, so it
can be posted on c.l.p.m

b.t.w., I have installed Activestate using the .msi package.

one additional thing:
many years ago, I installed "nmake" of the Visual C++ compiler suite,
maybe something tells EU::MM that it has to use "nmake" (and not
"dmake")

for example in ExtUtils\MM_Win32.pm:
[...]
sub init_DIRFILESEP {
    my($self) = shift;

    # The ^ makes sure its not interpreted as an escape in nmake
    $self->{DIRFILESEP} = $self->is_make_type('nmake') ? '^\\' :
                          $self->is_make_type('dmake') ? '\\\\'
                                                       : '\\';

}

However, I have checked my environment variables, but I could not find
anything related to "make", "dmake" or "nmake"

I have found the culprit in "Config.pm":

C:\>perl -MConfig -e "print $Config{make}"
nmake

I suspect this value should rather be "dmake" (am I right ?)

 

[sisyphus]

On Apr 20, 1:29 am, (e-mail address removed) wrote:

I suspect this value should rather be "dmake" (am I right ?)- Hide quotedtext -

No, I don't think so.
Sure, we want 'dmake' to be used, but that value of 'nmake' is being
overridden anyway. (You can check this by running 'perl -V:make',
which should report that make='dmake'.)

I guess, however, there's a chance that by some strange twist of fate,
it's not being overridden soon enough - so, in lib/Config_heavy.pl,
try changing:

make='nmake
to
make='dmake'

and see if that has any effect on the generated Makefile. (It should
alter the value of $Config{make} to 'dmake', but I'm not expecting any
other differences.)

I think, too, that the problem with 'rem' is another separate issue
(but nothing's guaranteed

Could you check that we're both looking at the same version of
EU::MM_Win32 (which defines DIRFILESEP) by running:

perl -MExtUtils::MM_Win32 -e "print $ExtUtils::MM_Win32::VERSION"

And check that it contains the following subroutine:

##################################
sub init_DIRFILESEP {
my($self) = shift;

my $make = $self->make;

# The ^ makes sure its not interpreted as an escape in nmake
$self->{DIRFILESEP} = $make eq 'nmake' ? '^\\' :
$make eq 'dmake' ? '\\\\'
: '\\';
}
##################################

I have version 6.42 of EU::MM_Win32.

Cheers,
Rob

 

[tuser1]

No, I don't think so.
Sure, we want 'dmake' to be used, but that value of 'nmake' is being
overridden anyway. (You can check this by running 'perl -V:make',
which should report that make='dmake'.)

I get
C:\>perl -V:make
make='nmake';

I guess, however, there's a chance that by some strange twist of fate,
it's not being overridden soon enough - so, in lib/Config_heavy.pl,
try changing:

make='nmake
to
make='dmake'

and see if that has any effect on the generated Makefile. (It should
alter the value of $Config{make} to 'dmake', but I'm not expecting any
other differences.)

I have changed lib/Config_heavy.pl into make='dmake', I deleted the
old Makefile and ran 'perl Makefile.PL, but there is no other
difference.

AR_STATIC_ARGS = cr
DIRFILESEP = ^\
DFSEP = $(DIRFILESEP)

so I changed my lib/Config_heavy.pl back to its original state
make='nmake'.

I think, too, that the problem with 'rem' is another separate issue
(but nothing's guaranteed

Could you check that we're both looking at the same version of
EU::MM_Win32 (which defines DIRFILESEP) by running:

perl -MExtUtils::MM_Win32 -e "print $ExtUtils::MM_Win32::VERSION"

And check that it contains the following subroutine:

##################################
sub init_DIRFILESEP {
    my($self) = shift;

    my $make = $self->make;

    # The ^ makes sure its not interpreted as an escape in nmake
    $self->{DIRFILESEP} = $make eq 'nmake' ? '^\\' :
                          $make eq 'dmake' ? '\\\\'
                                           : '\\';}

##################################

I have version 6.42 of EU::MM_Win32.

I have
C:\>perl -MExtUtils::MM_Win32 -e "print $ExtUtils::MM_Win32::VERSION"
6.50

(but this should not make any difference, because I upgraded EU::MM a
couple of hours ago,
but the problem was exactly the same before the upgrade)

Here is my init_DIRFILESEP...

**********************************
sub init_DIRFILESEP {
my($self) = shift;

# The ^ makes sure its not interpreted as an escape in nmake
$self->{DIRFILESEP} = $self->is_make_type('nmake') ? '^\\' :
$self->is_make_type('dmake') ? '\\\\'
: '\\';
}
**********************************

....which looks identical to yours

I believe that we have different values in "$self->make" (see sub
is_make_type in ExtUtils\MM_Win32.pm)

sub is_make_type {
my($self, $type) = @_;
return !! ($self->make =~ /\b$type(?:\.exe)?$/);
}

Where does the value "$self->make" originate ?

 

[tuser1]

Where does the value "$self->make" originate ?

I've found the problem...






....in "lib\ActivePerl\Config.pm":

******************************************************
sub override {
[...]
if ($key eq "make" && $^O eq "MSWin32") {
for (qw(nmake dmake)) {
if (ActiveState:ath::find_prog($_)) {
$_[0] = $OVERRIDE{$key} = $_;
return 1;
}
}
return 0;
}
******************************************************

("lib\ActivePerl\Config.pm" is called by the standard "lib\Config.pm")

I have an old version of "nmake" on my system, and my guess would be
that you have not.

The code in lib\ActivePerl\Config.pm is quite clever indeed:

First it looks if there exists an executable called "nmake". On my
configuration, there is one (albeit a very old one) and the subroutine
returns with $Config{make} = 'nmake'

I assume that on your configuration there is no such executable
'nmake', therefore it looks if there exists an executable called
"dmake", which there is, and the subroutine returns with $Config{make}
= 'dmake'

Here is what I did to resolve the issue on my system:

C:\dosext>ren NMAKE.EXE NMAKE-old.exe

And here is proof that "dmake" now works ok on my system:

C:\Scalar-Util-Refcount-1.0.2>perl -V:make
make='dmake';

C:\Scalar-Util-Refcount-1.0.2>perl Makefile.PL
Checking if your kit is complete...
Looks good
Writing Makefile for Scalar::Util::Refcount

C:\Scalar-Util-Refcount-1.0.2>dmake
gcc -c -DNDEBUG -DWIN32 -D_CONSOLE -DNO_STRICT -
DHAVE_DES_FCRYPT -DUSE_SITECUSTOMIZE -DPRIVLIB_LAST_IN_INC -
DPERL_IMPLICIT_CONTEXT -DPERL_IMPLICIT_SYS -DUSE_PERLIO -
DPERL_MSVCRT_REA
DFIX -DHASATTRIBUTE -fno-strict-aliasing -mms-bitfields -O2 -
DVERSION=\"1.0.2\" -DXS_VERSION=\"1.0.2\" "-IC:\Perl\lib\CORE"
Refcount_wrap.c
Running Mkbootstrap for Scalar::Util::Refcount ()
C:\Perl\bin\perl.exe -MExtUtils::Command -e chmod 644 Refcount.bs
dlltool --def Refcount.def --output-exp dll.exp
g++ -o blib\arch\auto\Scalar\Util\Refcount\Refcount.dll -Wl,--base-
file -Wl,dll.base -mdll -L"C:\Perl\lib\CORE" Refcount_wrap.o -Wl,--
image-base,0x3d100000 C:\Perl\lib\CORE\perl510.lib -lke
rnel32 -luser32 -lgdi32 -lwinspool -lcomdlg32 -ladvapi32 -lshell32 -
lole32 -loleaut32 -lnetapi32 -luuid -lws2_32 -lmpr -lwinmm -lversion -
lodbc32 -lodbccp32 -lmsvcrt dll.exp
dlltool --def Refcount.def --base-file dll.base --output-exp dll.exp
g++ -o blib\arch\auto\Scalar\Util\Refcount\Refcount.dll -mdll -L"C:
\Perl\lib\CORE" Refcount_wrap.o -Wl,--image-base,0x3d100000 C:\Perl
\lib\CORE\perl510.lib -lkernel32 -luser32 -lgdi32 -lwin
spool -lcomdlg32 -ladvapi32 -lshell32 -lole32 -loleaut32 -lnetapi32 -
luuid -lws2_32 -lmpr -lwinmm -lversion -lodbc32 -lodbccp32 -lmsvcrt
dll.exp
C:\Perl\bin\perl.exe -MExtUtils::Command -e chmod 755 blib\arch\auto
\Scalar\Util\Refcount\Refcount.dll
C:\Perl\bin\perl.exe -MExtUtils::Command -e cp Refcount.bs blib\arch
\auto\Scalar\Util\Refcount\Refcount.bs
C:\Perl\bin\perl.exe -MExtUtils::Command -e chmod 644 blib\arch\auto
\Scalar\Util\Refcount\Refcount.bs

C:\Scalar-Util-Refcount-1.0.2>dmake test
C:\Perl\bin\perl.exe "-MExtUtils::Command::MM" "-e" "test_harness(0,
'blib\lib', 'blib\arch')" t/*.t
t/10_test....ok
All tests successful.
Files=1, Tests=7, 0 wallclock secs ( 0.00 cusr + 0.00 csys = 0.00
CPU)

C:\Scalar-Util-Refcount-1.0.2>dmake install
Files found in blib\arch: installing files in blib\lib into
architecture dependent library tree
Installing C:\Perl\site\lib\auto\Scalar\Util\Refcount\Refcount.dll
Appending installation info to C:\Perl\lib/perllocal.pod

 

[tuser1]

("lib\ActivePerl\Config.pm" is called by the standard "lib\Config.pm")

I meant:

"lib\ActivePerl\Config.pm" is called by "lib\Config_heavy.pl", which,
in turn, is called by the standard "lib\Config.pm".

 

[sisyphus]

I've found the problem...

...in "lib\ActivePerl\Config.pm":

Yes - you've pretty much nailed it. And if I had been more astute and
thorough, the problem would have got solved considerably quicker.

Another way to resolve the matter is, instead of renaming nmake.exe,
to remove its location from the path. (I do have nmake.exe on my
system, but the location of that file is not in my path.)

I even managed to get the same errors as you by adding the location of
nmake.exe to my path.

Anyway, thanks for following this through, and sorry it dragged out
for so long. At least now we know that whenever we see that error it
simply means that nmake is being found, and the generated Makefile is
being written in accordance with nmake's syntax rules. (Yet another
solution would have been to run 'nmake' instead of 'dmake' - but if
it's that old crappy nmake-1.5, you don't really want to do that.)

Cheers,
Rob