Test failures on windows:

[ingydotnet]

See: http://www.cpantesters.org/cpan/report/76766494-6bf4-1014-9611-eb0e74c2f572

[ingydotnet]

See also: http://www.cpantesters.org/distro/I/Inline-C.html

[mohawk2]

As of 0.61, test 26fork is failing on all Win32, and only on Win32. The error is "Inline::Config" related. The code that gives such an error is in Inline.pm (not in Inline::C) at line 706:

croak M14_usage_Config() if %main::Inline::Config::;

I've improved that error message and we'll see what the next release brings in terms of errors!

[sisyphus]

With new message, the error is now:

" As of Inline v0.30, use of the Inline::Config module is no longer supported
or allowed. If Inline::Config exists on your system, it can be removed. See
the Inline documentation for information on how to configure Inline.

(Module was loaded from )"

Cheers,
Rob

[mohawk2]

The last bit " )" means %INC didn't have an Inline/Config.pm loaded. Could you do a quick search in your perl libdirs just to confirm that?

Reasoning: there are two places where the relevant error message (M14_usage_Config) is triggered, and one of them prepends "check_config_file". The lack of "check_config_file:" implies it was the other place, in create_config_file, and it actually did find an Inline/Config.pm and warned about it.

[sisyphus]

Definitely no Inline::Config in @inc - unless it's being momentarily created in '.' during the running of 'make test'.

Like I said before, this test script originally worked for me. What has changed ?

I can recall testing it - and it was I who put the Win32-specific conditional into it ... but I'm damned if I can find just where I tested this script (and excactly what it contained) when it passed.
It was probably done on my laptop - so I'll have a serious go at digging it up on it.
If I can find the instance where it was working, I can probably fix it by examining what has changed.

Cheers,
Rob

[sisyphus]

Results are all over the place.
On Windows XP, perl-5.14.0, Inline-0.55, 26fork.t passes all tests though it emits the following warning:
The process cannot access the file because it is being used by another process.

I amended a portion of the script:

my $pid = fork;
print "$$: Got to P\n";
eval { Inline->bind(C => 'int add(int x, int y) { return x + y; }'); };
print "$$: Got to Q\n";
exit 0 unless $pid;
print "$$: Got to R\n";
wait;

The output then becomes

4620: Got to P
-2224: Got to P
The process cannot access the file because it is being used by another process.
4620: Got to Q
4620: Got to R
-2224: Got to Q

It looks like the child's Inline->bind is being hampered by the parent's Inline->bind.

With Inline-0.56, same perl, same machine, same (altered) script, it just hangs - no output at all.
On Windows 7, Inline-0.55, perl-5.20.0, 26fork.t fails.

And then, when we get to the more recent Inline::C versions, the error changes again (as already reported).

At other times with Inline-C-0.60 I saw evidence of a race condition - I forget which perl versions they were, but sometimes the script would pass, other times not.

I think it's safe to say we're trying to do something that Windows doesn't accommodate reliably.

[mohawk2]

It's the DID locking mechanism that's the "issue". On Unix, that's done by opening-for-writing a lockfile and then using perl flock to acquire an exclusive lock on it, which blocks if something else already did so. It seems that Windows prevents the second lock-acquire-attempt by failing the open-for-write. I will explore an alternative.

[mohawk2]

On my Windows 7 Perl, open and flock work as they do on Unix. perl -V:

Summary of my perl5 (revision 5 version 18 subversion 1) configuration:

  Platform:
    osname=MSWin32, osvers=6.1, archname=MSWin32-x64-multi-thread
    uname=''
    config_args='undef'
    hint=recommended, useposix=true, d_sigaction=undef
    useithreads=define, usemultiplicity=define
    useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef
    use64bitint=define, use64bitall=undef, uselongdouble=undef
    usemymalloc=n, bincompat5005=undef
  Compiler:
    cc='gcc', ccflags =' -s -O2 -DWIN32 -DWIN64 -DCONSERVATIVE -DPERL_TEXTMODE_SCRIPTS -DUSE_SITECUSTOMIZE -DPERL_IMPLICIT_CONTEXT -DPERL_IMPLICIT_SYS -DUSE_PERLIO -fno-strict-aliasing -mms-bitfields',
    optimize='-s -O2',
    cppflags='-DWIN32'
    ccversion='', gccversion='4.6.3', gccosandvers=''
    intsize=4, longsize=4, ptrsize=8, doublesize=8, byteorder=12345678
    d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
    ivtype='long long', ivsize=8, nvtype='double', nvsize=8, Off_t='long long', lseeksize=8
    alignbytes=8, prototype=define
  Linker and Libraries:
    ld='g++', ldflags ='-s -static-libgcc -static-libstdc++ -L"C:\progra~1\Perl64\lib\CORE" -L"C:\MinGW\x86_64-w64-mingw32\lib"'
    libpth=C:\MinGW\x86_64-w64-mingw32\lib
    libs=-lmoldname -lkernel32 -luser32 -lgdi32 -lwinspool -lcomdlg32 -ladvapi32 -lshell32 -lole32 -loleaut32 -lnetapi32 -luuid -lws2_32 -lmpr -lwinmm -lversion -lodbc32 -lodbccp32 -lcomctl32
    perllibs=-lmoldname -lkernel32 -luser32 -lgdi32 -lwinspool -lcomdlg32 -ladvapi32 -lshell32 -lole32 -loleaut32 -lnetapi32 -luuid -lws2_32 -lmpr -lwinmm -lversion -lodbc32 -lodbccp32 -lcomctl32
    libc=, so=dll, useshrplib=true, libperl=libperl518.a
    gnulibc_version=''
  Dynamic Linking:
    dlsrc=dl_win32.xs, dlext=dll, d_dlsymun=undef, ccdlflags=' '
    cccdlflags=' ', lddlflags='-mdll -s -static-libgcc -static-libstdc++ -L"C:\progra~1\Perl64\lib\CORE" -L"C:\MinGW\x86_64-w64-mingw32\lib"'

Characteristics of this binary (from libperl): 
  Compile-time options: HAS_TIMES HAVE_INTERP_INTERN MULTIPLICITY
                        PERLIO_LAYERS PERL_DONT_CREATE_GVSV
                        PERL_HASH_FUNC_ONE_AT_A_TIME_HARD
                        PERL_IMPLICIT_CONTEXT PERL_IMPLICIT_SYS
                        PERL_MALLOC_WRAP PERL_PRESERVE_IVUV PERL_SAWAMPERSAND
                        USE_64_BIT_INT USE_ITHREADS USE_LARGE_FILES
                        USE_LOCALE USE_LOCALE_COLLATE USE_LOCALE_CTYPE
                        USE_LOCALE_NUMERIC USE_PERLIO USE_PERL_ATOF
                        USE_SITECUSTOMIZE
  Locally applied patches:
    ActivePerl Build 1800 [297570]
  Built under MSWin32
  Compiled at Sep 20 2013 15:07:17
  @INC:
    C:/Program Files/perl64/site/lib
    C:/Program Files/perl64/lib
    .

And this code:

use autodie;
use Fcntl ':flock';

$|=1;
open FH, '>', 'tf';
flock FH, LOCK_EX;
print 'lock';
sleep 5

Works as you'd think (when run in 2 different command prompt windows). Could you try this code in two windows on your box and see what happens?

[mohawk2]

It will help to sort this issue out if you could let me know what this does?

[sisyphus]

First one to get run prints "lock" immediately. Second one doesn't print "lock" until first one exits.
Seems the same for all versions of perl (including 5.12.0).

I've just TODO'd and pushed to git the failing tests (Windows only) on t/26fork.t. (Revert if you wish.)
That test script (as it was) invariably succeeds on perl-5.12.0 (32-bit and 64-bit) but invariably fails on (both 32-bit and 64-bit) perls 5.8.8, 5.8.9, 5.10.0, 5.14.0, 5.16.0, 5.18.0 and 5.20.0.

By "succeeds", I mean that all tests pass - I still don't know what's needed to get rmtree() to work.
I've also removed the experimental part of the message from Inline's M14 as it was contributing only noise - even to the TODO'd version of t/26fork.t.

I keep thinking the problem must be in Inline.pm, but the different behaviour of 5.12.0 is a puzzle.

[mohawk2]

Thanks for the lock test, shows the locking actually works on your Windows like it does on mine! That's reassuring, at least. I agree this issue is a bit mysterious.

I've released a new Inline, with a Data::Dumper of %Inline::Config for that error. I'll take a look at Inline::C tomorrow and make it depend on the latest Inline for a new dev release, and see how that behaves.

[mohawk2]

The Inline::Config issue I've dealt with for Inline v0.66 - it was a false positive (obviously) and now it uses $Inline::Config::VERSION as the check. Hopefully that's that one dealt with!

[mohawk2]

I claim this particular issue was related to Inline::Config detection, which is now resolved. We aren't out of the woods yet with Windows, but those more specific issues have GH issues open. I am therefore closing this one.