«

Hi,

Last month I was tinkering around with the Inline::C module. I
even posted a small program to comp.lang.perl.misc with the subject
"Curious benchmark results with Inline::C". (If you want to see it,
you can find it at:

http://groups.google.com/group/comp....0?dmode=source

)

Today I've gone back to that script and modified it a little. The
problem is, any change I make to the C code makes the code no longer
compile. If I leave the code untouched, then the script runs just
fine, but as soon as I make a small change (such as insert a space
somewhere), or even copy the script to a separate directory and run it
there, I get compiler errors.

For example, if I copy the "extra_function_c.pl" (found in the post
I referenced above) to my D:\tmp directory, cd to that directory, and
type:

perl extra_function_c.pl

I see the following output:

=== BEGIN OUTPUT ===
C:\strawberry\perl\bin\perl.exe C:\strawberry\perl\lib\ExtUtils
\xsubpp -typemap C:\strawberry\perl\lib\ExtUtils\typemap
extra_function_c_pl_850b.xs > extra_function_c_pl_850b.xsc && C:
\strawberry\perl\bin\perl.exe -MExtUtils::Command -e mv
extra_function_c_pl_850b.xsc extra_function_c_pl_850b.c
gcc -c -ID:/tmp -s -O2 -DWIN32 -DHAVE_DES_FCRYPT -
DPERL_IMPLICIT_CONTEXT -DPERL_IMPLICIT_SYS -fno-strict-aliasing -
DPERL_MSVCRT_READFIX -s -O2 -DVERSION=\"0.00\" -DXS_VERSION=
\"0.00\" "-IC:\strawberry\perl\lib\CORE" extra_function_c_pl_850b.c
Running Mkbootstrap for extra_function_c_pl_850b ()
C:\strawberry\perl\bin\perl.exe -MExtUtils::Command -e chmod 644
extra_function_c_pl_850b.bs
C:\strawberry\perl\bin\perl.exe -MExtUtils::Mksymlists \
-e "Mksymlists('NAME'=>\"extra_function_c_pl_850b \", 'DLBASE' =>
'extra_function_c_pl_850b', 'DL_FUNCS' => { }, 'FUNCLIST' => [],
'IMPORTS' => { }, 'DL_VARS' => []);"
dlltool --def extra_function_c_pl_850b.def --output-exp dll.exp
'dlltool' is not recognized as an internal or external command,
operable program or batch file.
dmake: Error code 129, while making 'blib\arch\auto
\extra_function_c_pl_850b\extra_function_c_pl_850b .dll'

A problem was encountered while attempting to compile and install your
Inline
C code. The command that failed was:
dmake > out.make 2>&1

The build directory was:
D:\tmp\_Inline\build\extra_function_c_pl_850b

To debug the problem, cd to the build directory, and inspect the
output files.

at extra_function_c.pl line 4
BEGIN failed--compilation aborted at extra_function_c.pl line 74.
=== END OUTPUT ===

It seems as though the problem starts around this line:

'dlltool' is not recognized as an internal or external command,
operable program or batch file.

I checked the C:\strawberry directory tree and no file named
dlltool.* appears to exist. Just in case it mysteriously disappeared
from my platform, I checked someone else's Strawberry Perl
installation, and he doesn't have it either.

Incidentally, I cd'ed to D:\tmp\_Inline\build
\extra_function_c_pl_850b and ran "dmake", and this is what I saw:

dlltool --def extra_function_c_pl_850b.def --output-exp dll.exp
'dlltool' is not recognized as an internal or external command,
operable program or batch file.
dmake: Error code 129, while making 'blib\arch\auto
\extra_function_c_pl_850b\extra_function_c_pl_850b .dll'

So it does seem likely that it's failing because "dlltool" can't be
found.

I'm puzzled here. Why did this program work just fine last month,
and today it's trying to run "dlltool", a program that seems to have
never existed in my Strawberry Perl installation in the first place?

Does anyone know how to get Inline::C working for me again? (I
reinstalled it with "cpan -fi Inline::C" but it didn't make any
difference.)

Thanks.

-- Jean-Luc

On Jan 14, 5:41 pm, Ben Morrow <b...@morrow.me.uk> wrote:
> Have you upgraded ExtUtils::MakeMaker in the meanwhile,
> or any other toolchain modules?

No, I haven't, although since you mentioned it, I tried re-
installing it with:

cpan -fi ExtUtils::MakeMaker

but that didn't seem to change anything. I finally got it working,
though, with your next suggestion:


> Well, you could always find a copy of dlltool
> (I presume it's part of GNU binutils for Win32)
> and put it in strawberry\c\bin.

I checked, and dlltool.exe was not in my GNU unix utilities for
Win32 (I'm not sure... is that the same as GNU binutils?). However, I
did a "find2perl" search on C:\ and eventually found dlltool.exe in C:
\Program Files\GCL-2.6.7-ANSI\mingw\mingw32\bin , so I copied it to C:
\strawberry\c\bin (the directory where gcc.exe resides).

This solved the problem! My Inline::C programs now compile.

Of course, I'm still puzzled as to why I could compile with no
problems last month and today I got errors relating to not finding
dlltool.exe . I don't recall ever installing mingw (perhaps
installing Strawberry Perl or Inline::C did it for me), but maybe the
mingw bin directory was in my path and somehow got removed recently.


> Inline::C checksums your source
> and skips the recompile if it's unchanged, so your old
> script isn't getting recompiled at all. If you clear out
> D:\tmp\_Inline you'll find the old script stops working
> too (which is actually a step forward, even though it may
> not seem like it).

Makes sense, as it would explain why there's multiple copies of
programs in the _Inline\lib\auto directory. This brings up the
question: If I modify the C code 20 times and run it after each
modification, will I have 20 cached programs in the _Inline
directory? Do the old cached programs ever go away, or do they
essentially stay around forever?

Anyway, thanks a million for your help, Ben.

-- Jean-Luc

On Jan 15, 1:00*pm, "jl_p...@hotmail.com" <jl_p...@hotmail.com> wrote:
> On Jan 14, 5:41 pm, Ben Morrow <b...@morrow.me.uk> wrote:

>*However, I
> did a "find2perl" search on C:\ and eventually found dlltool.exe in C:
> \Program Files\GCL-2.6.7-ANSI\mingw\mingw32\bin , so I copied it to C:
> \strawberry\c\bin (the directory where gcc.exe resides).

It definitely should already have been there in C:/strawberry/c/bin.
At some stage (as Ben suggested) it must have been deleted.

> This brings up the
> question: *If I modify the C code 20 times and run it after each
> modification, will I have 20 cached programs in the _Inline
> directory? *Do the old cached programs ever go away, or do they
> essentially stay around forever?

Yep - they stay there forever.
On Win32 I regularly run 'rmdir /s /q _Inline' to completely remove
the _Inline directory, and get rid of all of the old stuff.

Cheers,
Rob