[rt.cpan.org #85336] Fails often when tested in parallel
Tue Jul 01 04:27:36 2014: Request 85336 was acted upon.
Transaction: Correspondence added by SISYPHUS
Queue: Inline
Subject: Fails often when tested in parallel
Broken in: 0.53
Severity: (no value)
Owner: Nobody
Requestors: a...@cpan.org, ken...@cpan.org
Status: resolved
Ticket URL: https://rt.cpan.org/Ticket/Display.html?id=85336
Re-opening because of the following patch that was applied to Inline-0.55 as
part of this ticket:
Subject: [PATCH 4/5] MSWin32: disable BUILD_NOISY redirects on MSWin32 with
cmd.exe
also print exitcode with failed commands
diff --git C/C.pm C/C.pm
index f76e34b..21f7dfe 100644
--- C/C.pm
+++ C/C.pm
@@ -804,6 +804,7 @@ sub makefile_pl {
-f ($perl = $Config::Config{perlpath})
or ($perl = $^X)
or croak Can't locate your perl binary;
+$perl = qq{$perl} if $perl =~ m/\s/;
$o-system_call($perl Makefile.PL, 'out.Makefile_PL');
$o-fix_make;
}
@@ -841,6 +842,7 @@ sub system_call {
defined $ENV{PERL_INLINE_BUILD_NOISY}
? $ENV{PERL_INLINE_BUILD_NOISY}
: $o-{CONFIG}{BUILD_NOISY};
+$build_noisy = undef if $build_noisy and $^O eq 'MSWin32' and
$Config::Config{sh} =~ /^cmd/;
if (not $build_noisy) {
$cmd = $cmd $output_file 21;
}
@@ -861,11 +863,12 @@ sub build_error_message {
close OUTPUT;
}
+my $errcode = $? 8;
return $output . END;
A problem was encountered while attempting to compile and install your Inline
$o-{API}{language} code. The command that failed was:
- $cmd
+ \$cmd\ with error code $errcode
The build directory was:
$build_dir
I wondered at the time (and still wonder) what that was about - but I applied
it anyway, as it didn't break any tests.
However, it does break BUILD_NOISY on Win32 - to the extent that the
compiler/linker commands/warnings of a successful build are not seen.
simply removing the line:
$build_noisy = undef if $build_noisy and $^O eq 'MSWin32' and
$Config::Config{sh} =~ /^cmd/;
from the patched (0.55) C.pm is sufficient to regain correct functioning of
BUILD_NOISY on Windows.
However, doing that probably also destroys whatever it was that the patch was
designed to fix.
This episode exposes a need for a test script that examines the output of a
BUILD_NOISY build to detect that this output is present.
It would be hard to check that the entire output is as it should be, but we
should at least be able to check for the presence of certain key elements like
- eg that the output matches the string perl, that it matches the
(interpolated)$Config{LD} and that it matches the name of any Inline-C
function whose compilation is expected to emit a warning.
I think this breakage of BUILD_NOISY needs to be fixed for the next stable
release.
Attached is a try.pl that demonstrates the problem. It shows the expected
output of the script, and the actual output I get on one of my Win32 perls
using Inline-0.55.
Cheers,
Rob
use strict;
use warnings;
use Inline C = Config =
BUILD_NOISY = 1,
;
use Inline C = 'EOC';
void inline_warner() {
int *x;
x = 2;
}
EOC
print DONE;
__END__
Should output (for me on Windows):
#
validate Stage
Starting Build Preprocess Stage
get_maps Stage
Finished Build Preprocess Stage
Starting Build Parse Stage
Finished Build Parse Stage
Starting Build Glue 1 Stage
Finished Build Glue 1 Stage
Starting Build Glue 2 Stage
Finished Build Glue 2 Stage
Starting Build Glue 3 Stage
Finished Build Glue 3 Stage
Starting Build Compile Stage
Starting perl Makefile.PL Stage
Writing Makefile for try_pl_534c
Writing MYMETA.yml
Finished perl Makefile.PL Stage
Starting make Stage
C:\perl514_M\bin\perl.exe C:\perl514_M\lib\ExtUtils\xsubpp -typemap C:\perl514_M\lib\ExtUtils\typemap -typemap C:\_32\pscrpt\inline\typemap try_pl_534c.xs try_pl_534c.xsc C:\perl514_M\bin\perl.exe -MExtUtils::Command -e mv -- try_pl_534c.xsc try_pl_534c.c
gcc -c -IC:/_32/pscrpt/inline -s -O2 -DWIN32 -DPERL_TEXTMODE_SCRIPTS -DPERL_IMPLICIT_CONTEXT -DPERL_IMPLICIT_SYS -fno-strict-aliasing -mms-bitfields -s -O2 -DVERSION=\0.00\ -DXS_VERSION=\0.00\ -IC:\perl514_M\lib\CORE try_pl_534c.c
try_pl_534c.xs: In function `inline_warner':
try_pl_534c.xs:8: warning: assignment makes pointer from integer without a cast
Running Mkbootstrap for try_pl_534c ()
C:\perl514_M\bin\perl.exe -MExtUtils::Command -e chmod -- 644 try_pl_534c.bs
C:\perl514_M\bin\perl.exe -MExtUtils::Mksymlists \
-e Mksymlists('NAME'=\try_pl_534c\, 'DLBASE' = 'try_pl_534c', 'DL_FUNCS' = { }, 'FUNCLIST' = [], 'IMPORTS' = { }, 'DL_VARS' = []);
dlltool --def try_pl_534c.def --output-exp dll.exp
g++ -o blib\arch\auto\try_pl_534c\try_pl_534c.dll -Wl,--base-file -Wl,dll.base -mdll -s -Lc:\perl514_M\lib\CORE -LC:\home\rob\mingw_vista\i686-pc-mingw32\lib try_pl_534c.o C:\perl514_M\lib\CORE\libperl514.a
[rt.cpan.org #95809] [PATCH] Using Inline in a distribution with multiple modules
Tue Jun 24 03:47:40 2014: Request 95809 was acted upon. Transaction: Correspondence added by SISYPHUS Queue: Inline Subject: [PATCH] Using Inline in a distribution with multiple modules Broken in: (no value) Severity: (no value) Owner: Nobody Requestors: s...@parasite.cc Status: open Ticket URL: https://rt.cpan.org/Ticket/Display.html?id=95809 Fixed as of Inline-0.55_01
[rt.cpan.org #17415] Problem with PAR and Inline
Tue Jun 24 03:53:35 2014: Request 17415 was acted upon. Transaction: Correspondence added by SISYPHUS Queue: Inline Subject: Problem with PAR and Inline Broken in: 0.44 Severity: (no value) Owner: Nobody Requestors: joh...@darserman.com, jona...@cpan.org Status: open Ticket URL: https://rt.cpan.org/Ticket/Display.html?id=17415 Should be addressed from within PAR
[rt.cpan.org #19624] Inline::Structs Configuration of LIB and INC are ignored when using structs
Tue Jun 24 04:01:51 2014: Request 19624 was acted upon. Transaction: Correspondence added by SISYPHUS Queue: Inline Subject: Inline::Structs Configuration of LIB and INC are ignored when using structs Broken in: 0.44 Severity: Important Owner: Nobody Requestors: roger.wy...@nomadsoft.com Status: open Ticket URL: https://rt.cpan.org/Ticket/Display.html?id=19624 Inline::Structs is old, buggy and not used - currently irrelevant
[rt.cpan.org #7138] installation problems when no read permissions in some parent directories
Tue Jun 24 04:07:29 2014: Request 7138 was acted upon. Transaction: Correspondence added by SISYPHUS Queue: Inline Subject: installation problems when no read permissions in some parent directories Broken in: (no value) Severity: (no value) Owner: Nobody Requestors: nedk...@cpan.org Status: open Ticket URL: https://rt.cpan.org/Ticket/Display.html?id=7138 Apparently no longer an issue. (Was this *ever* something that Inline should have to deal with ?)
[rt.cpan.org #13285] Inline breaks down when run in two processes at once
Tue Jun 24 04:21:23 2014: Request 13285 was acted upon. Transaction: Correspondence added by SISYPHUS Queue: Inline Subject: Inline breaks down when run in two processes at once Broken in: (no value) Severity: Normal Owner: Nobody Requestors: dstah...@gi.alaska.edu Status: open Ticket URL: https://rt.cpan.org/Ticket/Display.html?id=13285 Fixed as of Inline-0.55_01
[rt.cpan.org #69884] Require newer Digest::MD5
Tue Jun 24 04:25:13 2014: Request 69884 was acted upon. Transaction: Correspondence added by SISYPHUS Queue: Inline Subject: Require newer Digest::MD5 Broken in: (no value) Severity: (no value) Owner: Nobody Requestors: n...@detonation.org Status: open Ticket URL: https://rt.cpan.org/Ticket/Display.html?id=69884 Lack of follow-up.
[rt.cpan.org #58171]
Tue Jun 24 04:28:23 2014: Request 58171 was acted upon. Transaction: Correspondence added by SISYPHUS Queue: Inline Subject: (No subject given) Broken in: 0.46, 0.46_01 Severity: Normal Owner: Nobody Requestors: jolemar...@gmail.com Status: open Ticket URL: https://rt.cpan.org/Ticket/Display.html?id=58171 Lack of follow-up
[rt.cpan.org #55543] Inline::C can crash the perl interpreter if function uses PUSHMARK
Tue Jun 24 04:31:49 2014: Request 55543 was acted upon. Transaction: Correspondence added by SISYPHUS Queue: Inline Subject: Inline::C can crash the perl interpreter if function uses PUSHMARK Broken in: (no value) Severity: (no value) Owner: Nobody Requestors: asuffi...@suffields.me.uk Status: open Ticket URL: https://rt.cpan.org/Ticket/Display.html?id=55543 Lack of follow-up
[rt.cpan.org #44587] make test bug
Tue Jun 24 04:39:51 2014: Request 44587 was acted upon. Transaction: Correspondence added by SISYPHUS Queue: Inline Subject: make test bug Broken in: (no value) Severity: (no value) Owner: Nobody Requestors: alefn...@yahoo.com Status: new Ticket URL: https://rt.cpan.org/Ticket/Display.html?id=44587 Lack of specific information.
[rt.cpan.org #7552] Inline::MakeMaker doesn't work with win32 (nmake) (indication for a fix)
Tue Jun 24 04:44:16 2014: Request 7552 was acted upon. Transaction: Correspondence added by SISYPHUS Queue: Inline Subject: Inline::MakeMaker doesn't work with win32 (nmake) (indication for a fix) Broken in: (no value) Severity: Important Owner: Nobody Requestors: joh...@cpan.org Status: open Ticket URL: https://rt.cpan.org/Ticket/Display.html?id=7552 Fixed as of 0.55_01 (Duplicated by #95809).
[rt.cpan.org #6806] [as5.8.3/winxp] output dir exception when dir contains spaces (workarround included)
Tue Jun 24 04:50:08 2014: Request 6806 was acted upon. Transaction: Correspondence added by SISYPHUS Queue: Inline Subject: [as5.8.3/winxp] output dir exception when dir contains spaces (workarround included) Broken in: (no value) Severity: Normal Owner: Nobody Requestors: muena...@cpan.org Status: new Ticket URL: https://rt.cpan.org/Ticket/Display.html?id=6806 Too old (10 years +) to warrant investigation.
[rt.cpan.org #96291] t/08taint.t fails on perl 5.20.0
Tue Jun 24 05:01:44 2014: Request 96291 was acted upon. Transaction: Correspondence added by SISYPHUS Queue: Inline Subject: t/08taint.t fails on perl 5.20.0 Broken in: 0.55 Severity: (no value) Owner: Nobody Requestors: e...@cpan.org Status: open Ticket URL: https://rt.cpan.org/Ticket/Display.html?id=96291 Fixed as of 0.55_02
[rt.cpan.org #85336] Fails often when tested in parallel
Tue Jun 24 05:06:27 2014: Request 85336 was acted upon. Transaction: Correspondence added by SISYPHUS Queue: Inline Subject: Fails often when tested in parallel Broken in: 0.53 Severity: (no value) Owner: Nobody Requestors: a...@cpan.org, ken...@cpan.org Status: open Ticket URL: https://rt.cpan.org/Ticket/Display.html?id=85336 Fixed as of 0.55_01
[rt.cpan.org #95624] cpan as root cannot install Inline without force
Tue Jun 24 05:08:35 2014: Request 95624 was acted upon. Transaction: Correspondence added by SISYPHUS Queue: Inline Subject: cpan as root cannot install Inline without force Broken in: (no value) Severity: (no value) Owner: Nobody Requestors: jeff.ja...@gmail.com Status: open Ticket URL: https://rt.cpan.org/Ticket/Display.html?id=95624 Fixed as of 0.55_01
[rt.cpan.org #5465] Fails to detect C functions taking (void)
Tue Jun 24 08:36:54 2014: Request 5465 was acted upon. Transaction: Correspondence added by SISYPHUS Queue: Inline Subject: Fails to detect C functions taking (void) Broken in: (no value) Severity: Normal Owner: Nobody Requestors: q...@laxan.com Status: open Ticket URL: https://rt.cpan.org/Ticket/Display.html?id=5465 On Sun Jun 22 22:40:39 2014, ETJ wrote: It passes, so looks like this bug is now no longer applicable. Just for the record, the bug still stands for the ParseRecRescent parser - it was just that the particular script being run did not detect the bug. Cheers, Rob
[rt.cpan.org #96291] t/08taint.t fails on perl 5.20.0
Sun Jun 22 07:05:25 2014: Request 96291 was acted upon. Transaction: Correspondence added by SISYPHUS Queue: Inline Subject: t/08taint.t fails on perl 5.20.0 Broken in: 0.55 Severity: (no value) Owner: Nobody Requestors: e...@cpan.org Status: open Ticket URL: https://rt.cpan.org/Ticket/Display.html?id=96291 On Sat Jun 21 22:28:50 2014, ETJ wrote: Instead, this patch (replacing previous two) actually tests $ != $, which revealed a couple of quirks, hence a couple of extra changes: Thanks Ed - checks out ok here, so I've applied the patches and released Inline-0.55_02. On Windows both $ and $ are 0 and cannot be altered as seteuid() and setruid() are not implemented. In C/t/08taint.t I therefore had to make the setting of $ to 1 conditional upon OS not being Windows (to avoid fatal error on that OS). With that in place, everything tests fine for me on Windows, Cygwin, Ubuntu and Debian Wheezy. Now we sit back and see what the smokers/testers throw at us :-) Cheers, Rob
[rt.cpan.org #96291] t/08taint.t fails on perl 5.20.0
Fri Jun 20 23:56:25 2014: Request 96291 was acted upon.
Transaction: Correspondence added by SISYPHUS
Queue: Inline
Subject: t/08taint.t fails on perl 5.20.0
Broken in: 0.55
Severity: (no value)
Owner: Nobody
Requestors: e...@cpan.org
Status: open
Ticket URL: https://rt.cpan.org/Ticket/Display.html?id=96291
Inline-0.55_01 was released a couple of days ago, partly to see how t/08taint.t
fares following the latest round of amendments to the Inline code.
I've just received the first FAIL report for 0.55_01:
http://www.cpantesters.org/cpan/report/a3185cf8-f82f-11e3-919b-572b4803b899
The culprit is, of course, C/t/08taint.t.
What to do wrt this ?
If it's fixable, and we can fix it, then I guess we should do that.
If we can't fix it, then we need to detect in advance that the failure will
occur and either SKIP or TODO the remaining 9 tests.
There's a couple of issues with taking the TODO route:
1) The script is actually dying before all tests have been run - so I don't
think TODO'ing the remaining tests is going to prevent the script from being
reported as a FAIL. (We can probably workaround that by running the remaining
tests inside eval{}.)
2) 3 of the tests are warnings_like() from Test::Warn, and it seems that TODO
is ignored for them. That being so, we need to work around that shortcoming,
too. (I was unable to find a way to make those 3 tests honor TODO - but that
doesn't necessarily mean it can't be done.)
However, I think that if there's no chance of Inline being able to run
correctly under -T on a particular system, then we are quite entitled to SKIP
those tests on that system.
Thoughts ?
Cheers,
Rob
[rt.cpan.org #95809] [PATCH] Using Inline in a distribution with multiple modules
Sat Jun 21 00:21:40 2014: Request 95809 was acted upon. Transaction: Correspondence added by SISYPHUS Queue: Inline Subject: [PATCH] Using Inline in a distribution with multiple modules Broken in: (no value) Severity: (no value) Owner: Nobody Requestors: s...@parasite.cc Status: open Ticket URL: https://rt.cpan.org/Ticket/Display.html?id=95809 Inline-0.55_01, which contains the fix for this bug was released to CPAN on 19th June 2014. There's no testing of this specific bugfix in the test suite, though there are the 2 demo modules modules/Math-Simple-1.23 and modules/Boo-2.01 - both of which should build and test fine as a result of this bugfix. Math-Simple-1.23 has always built fine, but Boo-2.01 (added with this latest release) does not build correctly with earlier versions of Inline. Cheers, Rob
[rt.cpan.org #95809] [PATCH] Using Inline in a distribution with multiple modules
Sun Jun 15 00:25:15 2014: Request 95809 was acted upon. Transaction: Correspondence added by SISYPHUS Queue: Inline Subject: [PATCH] Using Inline in a distribution with multiple modules Broken in: (no value) Severity: (no value) Owner: Nobody Requestors: s...@parasite.cc Status: open Ticket URL: https://rt.cpan.org/Ticket/Display.html?id=95809 Hopefully that'll make more sense when you have a look at it. Looks good to me. Sub satisfy_makefile_dep() would perhaps be better placed in MakeMaker.pm but I don't see any imperative to move it there - especially since it's doing stuff that was already being done in Inline.pm (as you noted). I'll get Inline-0.55_01 out in the next week, and we'll see how it goes. Thanks for your work !! Cheers, Rob
[rt.cpan.org #95809] [PATCH] Using Inline in a distribution with multiple modules
Fri Jun 13 06:29:43 2014: Request 95809 was acted upon.
Transaction: Correspondence added by SISYPHUS
Queue: Inline
Subject: [PATCH] Using Inline in a distribution with multiple modules
Broken in: (no value)
Severity: (no value)
Owner: Nobody
Requestors: s...@parasite.cc
Status: open
Ticket URL: https://rt.cpan.org/Ticket/Display.html?id=95809
How about the attached version of lib/Inline/Makemaker.pm ?
It seems to do things right for me on Windows.
Cheers,
Rob
package Inline::MakeMaker;
$Inline::MakeMaker::VERSION = '0.55';
$Inline::MakeMaker::VERSION = eval $Inline::MakeMaker::VERSION;
@EXPORT = qw(WriteMakefile WriteInlineMakefile);
use strict;
use base 'Exporter';
use ExtUtils::MakeMaker();
use Carp;
sub WriteInlineMakefile {
#warn END;
#
#Inline::MakeMaker::WriteInlineMakefile() is deprecated as of Inline-0.44.
#Inline::MakeMaker::WriteMakefile() should be used instead.
#
#END
goto WriteMakefile;
}
sub WriteMakefile {
my %args = @_;
my $name = $args{NAME}
or croak Inline::MakeMaker::WriteMakefile requires the NAME parameter\n;
my $version = '';
croak END unless (defined $args{VERSION} or defined $args{VERSION_FROM});
Inline::MakeMaker::WriteMakefile requires either the VERSION or VERSION_FROM
parameter.
END
if (defined $args{VERSION}) {
$version = $args{VERSION};
}
else {
$version = ExtUtils::MM_Unix-parse_version($args{VERSION_FROM})
or croak Can't determine version for $name\n;
}
croak END unless $version =~ /^\d\.\d\d$/;
Invalid version '$version' for $name.
Must be of the form '#.##'. (For instance '1.23')
END
# Provide a convenience rule to clean up Inline's messes
$args{clean} = { FILES = _Inline *.inl }
unless defined $args{clean};
# Add Inline to the dependencies
$args{PREREQ_PM}{Inline} = '0.44' unless defined $args{PREREQ_PM}{Inline};
my $mm = ExtUtils::MakeMaker::WriteMakefile(%args);
my (@objects, @obj_rules);
if (@{$mm-{PMLIBDIRS}} $mm-{PM}) { #line 55 SIS alteration
# Sort them longest first so we'll match subdirectories before their parents
my @libdirs = sort { length($b) = length($a) } @{$mm-{PMLIBDIRS}};
for my $path (keys %{$mm-{PM}}) {
for my $lib (@libdirs) {
if (index($path,$lib) == 0) {
my ($vol, $dirs, $file) = File::Spec-splitpath(substr($path, length($lib)+1));
my @dirs = File::Spec-splitdir($dirs);
pop @dirs unless length($dirs[$#dirs]);
$file =~ s/\.[^.]+$//;
push @objects, join('::', @dirs, $file);
push @obj_rules, join('-', @dirs, $file.inl);
last;
}
croak Failed to find module path for '$path';
}
}
} else {
# no modules found in PMLIBDIRS so assume we've just got $name to do
@objects = $name;
$name =~ s/::/-/g;
@obj_rules = ($name.inl);
#@obj_rules = (split(/::/, $name))[-1].'.inl';
}
if (@objects) {
open MAKEFILE, ' Makefile'
or croak Inline::MakeMaker::WriteMakefile can't append to Makefile:\n$!;
print MAKEFILE MAKEFILE;
# Well, not quite. Inline::MakeMaker is adding this:
# --- MakeMaker inline section:
MAKEFILE
for (0..$#objects) {
print MAKEFILE MAKEFILE;
$obj_rules[$_]: \$(TO_INST_PM)
\$(PERL) -Mblib -MInline=NOISY,_INSTALL_ -M$objects[$_] -e1 $version \$(INST_ARCHLIB)
\$(PERL) -e open WR, '', '$obj_rules[$_]' unless -e '$obj_rules[$_]';
MAKEFILE
}
print MAKEFILE \npure_all :: ,join(' ',@obj_rules),\n;
print MAKEFILE MAKEFILE;
# The End is here.
MAKEFILE
close MAKEFILE;
}
}
1;
[rt.cpan.org #95809] [PATCH] Using Inline in a distribution with multiple modules
Wed Jun 11 03:24:13 2014: Request 95809 was acted upon.
Transaction: Correspondence added by SISYPHUS
Queue: Inline
Subject: [PATCH] Using Inline in a distribution with multiple modules
Broken in: (no value)
Severity: (no value)
Owner: Nobody
Requestors: s...@parasite.cc
Status: open
Ticket URL: https://rt.cpan.org/Ticket/Display.html?id=95809
On Mon Jun 09 22:45:21 2014, s...@parasite.cc wrote:
Ok I'll check into that too :). Now I just have to find some time this
week...
Hi Jason,
The problem seems to be mostly fixed if, at line 55 of (your patched)
lib/Inline/Makemaker.pm we change:
if ($mm-{PMLIBDIRS} $mm-{PM}) {
to:
if (@{$mm-{PMLIBDIRS}} $mm-{PM}) {
That at least allows both layouts to build and install as desired. On the
perls I've just tested, an array reference is true even if the array being
referenced is empty - hence the need for the alteration.
However, that change doesn't fix the annoyance of having the compilation re-run
during each of the make steps (which happens because the specified .inl target
is not met).
Incidentally, for a long time Inline has shipped with the demo module named
Math::Simple-1.23.
It was always packed into the source as:
modules/Math/Simple/Changes
modules/Math/Simple/Makefile.PL
modules/Math/Simple/MANIFEST
modules/Math/Simple/Simple.pl
modules/Math/Simple/test.pl
In git (https://github.com/ingydotnet/inline-pm), I've now rearranged that as
the more usual:
modules/Math-Simple-1.23/Changes
modules/Math-Simple-1.23/Makefile.PL
modules/Math-Simple-1.23/MANIFEST
modules/Math-Simple-1.23/Simple.pl
modules/Math-Simple-1.23/test.pl
And I've also added a second demo which is essentially the same distro as the
one we've been using as our reference. (I've changed the names of the modules
from Foo, Foo::Bar, and Foo::Bar::Baz to Boo, Boo::Far and Boo::Far::Faz -
other than that it's the same).
So, in git, you'll also find:
modules/Boo-2.01/lib/Boo.pm
modules/Boo-2.01/lib/Boo/Far.pm
modules/Boo-2.01/lib/Boo/Far/Faz.pm
modules/Boo-2.01/Makefile.PL
modules/Boo-2.01/MANIFEST
modules/Boo-2.01/t/boo.t
These files will, of course ship with future Inline releases as demos of the 2
layouts.
Naturally, what we want is for both of those demos to build correctly out of
the box.
With the above alteration to your patched MakeMaker.pm I think they do that -
except that Math-Simple-1.23 wants to recompile the C code at every 'make' step.
Cheers,
Rob
[rt.cpan.org #92144] can't find gcc-4 on cygwin (patch to fix)
Sun Apr 06 03:38:41 2014: Request 92144 was acted upon.
Transaction: Correspondence added by SISYPHUS
Queue: Inline
Subject: can't find gcc-4 on cygwin (patch to fix)
Broken in: (no value)
Severity: (no value)
Owner: Nobody
Requestors: plice...@cpan.org
Status: open
Ticket URL: https://rt.cpan.org/Ticket/Display.html?id=92144
On Tue Jan 14 10:43:07 2014, PLICEASE wrote:
--- a/C/Makefile.PL
+++ b/C/Makefile.PL
@@ -5,6 +5,7 @@ use File::Spec;
my ($cc, $exe) = @Config{'cc', '_exe'};
$cc =~ s/\s+-.+$//; #remove possible trailing options
+$exe = '' if $^O eq 'cygwin';
my $found = 0;
my $delim = $Config::Config{path_sep};
Sorry - I missed this bug report when I was preparing for 0.54 to be released.
I've just released 0.54_01 to CPAN. It has been patched as per the quoted
patch. It also includes the patches provided by rurban in his submission to
ticket #85336.
If 0.54_01 tests ok, it will be released as 0.55 in about a week's time.
Cheers,
Rob
[rt.cpan.org #85336] Fails often when tested in parallel
Sun Apr 06 03:55:40 2014: Request 85336 was acted upon.
Transaction: Correspondence added by SISYPHUS
Queue: Inline
Subject: Fails often when tested in parallel
Broken in: 0.53
Severity: (no value)
Owner: Nobody
Requestors: a...@cpan.org, ken...@cpan.org
Status: open
Ticket URL: https://rt.cpan.org/Ticket/Display.html?id=85336
On Fri Apr 04 14:02:09 2014, rur...@x-ray.at wrote:
Patches for the next release attached
Thanks Reini.
These patches have been applied (by hand) hope I got 'em right.
Inline-0.54_01 (which contains these patches) has now been uploaded to CPAN.
All being well, it will be re-released as Inline-0.55 in a week or so.
For the Changes and C/Changes files I generally structure it so that Changes
lists alterations to Inline and C/Changes alterations to Inline::C. (All this
really achieves is to make it difficult for myself - especially in those cases
where both packages are affected by the one set of changes.)
One will find that Changes and C/Changes have not been altered in strict
accordance with the provided patches.
The only other alteration made to the provided patches was to rewrite the 2
occurrences of:
local $ENV{MAKEFLAGS} = $ENV{MAKEFLAGS} =~ s/(--jobserver-fds=[\d,]+)//;
as:
if($ENV{MAKEFLAGS}) {
local $ENV{MAKEFLAGS} = $ENV{MAKEFLAGS} =~ s/(--jobserver-fds=[\d,]+)//;
}
This was done to avoid 'uninitialized' warnings on systems where
$ENV{MAKEFLAGS} was unset.
Cheers,
Rob
[rt.cpan.org #85336] Fails often when tested in parallel
Sat May 18 02:20:38 2013: Request 85336 was acted upon. Transaction: Correspondence added by SISYPHUS Queue: Inline Subject: Fails often when tested in parallel Broken in: 0.53 Severity: (no value) Owner: Nobody Requestors: a...@cpan.org Status: new Ticket URL: https://rt.cpan.org/Ticket/Display.html?id=85336 On Wed May 15 23:11:13 2013, ANDK wrote: There seems to be a race condition somewhere. Both of the affected test scripts (t/21read_DATA.t and t/22read_DATA.t) use the same Inline build directory (.Inline) - and they therefore need to access the same configuration file. If you think that could be the source of the problem, I could work around that by designating 2 different (separate) build directories for those 2 test scripts - thereby assuring that each script has its own copy of the configuration details. Is that worth trying ? (If so, let me know, and I'll upload a new developer version of Inline that does exactly that and we can see how that goes.) Cheers, Rob
[rt.cpan.org #85336] Fails often when tested in parallel
Sun May 19 01:37:37 2013: Request 85336 was acted upon. Transaction: Correspondence added by SISYPHUS Queue: Inline Subject: Fails often when tested in parallel Broken in: 0.53 Severity: (no value) Owner: Nobody Requestors: a...@cpan.org Status: open Ticket URL: https://rt.cpan.org/Ticket/Display.html?id=85336 On Sat May 18 10:40:47 2013, andreas.koenig.7os6v...@franz.ak.mind.de wrote: Sisyphus via RT bug-inl...@rt.cpan.org writes: Is that worth trying ? This, or maybe apply some locking? Depends on how much work it is, and on how relevant for later real world behaviour it is. Except for this, I'd leave the judgement to the implementor;) I don't think it's very relevant to real world usage - and hence my (personal) interest in this is nowhere near as keen as it would otherwise be. However, David Oswald wants to write some patches that will put in place file locking. If there's no problem with those patches, I'll apply them (when I receive them) and release a new devel version of Inline. Hopefully, that will keep everyone happy :-) Cheers, Rob
[rt.cpan.org #11748] Inline::CPP config gets lost because of Inline::C bug
Wed May 08 22:45:09 2013: Request 11748 was acted upon. Transaction: Correspondence added by SISYPHUS Queue: Inline Subject: Inline::CPP config gets lost because of Inline::C bug Broken in: (no value) Severity: Important Owner: Nobody Requestors: nick_...@pisem.net Status: open Ticket URL: https://rt.cpan.org/Ticket/Display.html?id=11748 Marking as resolved. Fixed in Inline-0.53 (which was released to CPAN on 30th April 2013). Cheers, Rob
[rt.cpan.org #11748] Inline::CPP config gets lost because of Inline::C bug
Tue Apr 23 23:49:15 2013: Request 11748 was acted upon.
Transaction: Correspondence added by SISYPHUS
Queue: Inline
Subject: Inline::CPP config gets lost because of Inline::C bug
Broken in: (no value)
Severity: Important
Owner: Nobody
Requestors: nick_...@pisem.net
Status: open
Ticket URL: https://rt.cpan.org/Ticket/Display.html?id=11748
On Sat Apr 20 02:53:07 2013, iang wrote:
I think the fault is in Inline::CPP, not Inline::C.
Yes, I now think that *is* right.
If Inline::CPP
generates typemap data (if $typemap has non-zero length in
Inline::CPP::write_typemap) then Inline::CPP::validate is called
with the generated TYPEMAP data passed, but this calls
Inline::C::validate, which sets $o-{ILSM}{MAKEFILE}{INC}, unless
$o-UNTAINT is set.
[snip]
Part of the issue is that when validating TYPEMAP, all the other
options are not passed to Inlince::C::validate. The initialization
there sets INC and the previously passed value is not appended
because it is not passed, only the TYPEMAP is passed.
Seems to me that Inline::C::validate is not really designed to receive that set
of data, and Inline::CPP should probably not be passing that set of data to it.
Nevertheless, it can apparently be easily fixed by applying the suggested
change to Inline::C::validate - so I'll go with the original fix.
A version of Inline containing this fix has been uploaded to CPAN as
Inline-0.52_02. Unless, in the meantine, there's an issue found with
Inline-0.52_02, it will be released as Inline-0.53 early next week.
Thanks again, Ian, for for the digging and the demo case.
Cheers,
Rob
[rt.cpan.org #11748] Inline::CPP config gets lost because of Inline::C bug
Sat Apr 20 07:06:17 2013: Request 11748 was acted upon. Transaction: Correspondence added by SISYPHUS Queue: Inline Subject: Inline::CPP config gets lost because of Inline::C bug Broken in: (no value) Severity: Important Owner: Nobody Requestors: nick_...@pisem.net Status: open Ticket URL: https://rt.cpan.org/Ticket/Display.html?id=11748 On Sat Apr 20 04:43:46 2013, iang wrote: I have looked at this a little further and, while I don't see any evidence of a bug in Inline::C, the bug in Inline::CPP (see Bug #84762) can be fixed by a change to Inline::C. Thanks for the test case - and for digging around and providing ideas on how to fix this. Now that I have a demo to study, I can see that the '-IC:/' gets lost inside Inline::C::validate (which is called near the end of Inline::CPP::validate). This would suggest to me that it *is* a bug in Inline::C. I'll do something about this when I get the time to study more closely what's going on. (Should have some time for that within the next fortnight.) Thanks again, Ian. Cheers, Rob
[rt.cpan.org #81375] chdir without cc
Wed Mar 06 21:13:29 2013: Request 81375 was acted upon. Transaction: Correspondence added by SISYPHUS Queue: Inline Subject: chdir without cc Broken in: 0.50 Severity: Normal Owner: Nobody Requestors: bernhard+c...@lsmod.de Status: open Ticket URL: https://rt.cpan.org/Ticket/Display.html?id=81375 Fixed in 0.52. Thank you for the report.
[rt.cpan.org #81172] using Inline with = 'Event' fails to compile
Wed Mar 06 21:14:30 2013: Request 81172 was acted upon. Transaction: Correspondence added by SISYPHUS Queue: Inline Subject: using Inline with = 'Event' fails to compile Broken in: (no value) Severity: (no value) Owner: Nobody Requestors: peter.smoczyn...@i-new.com Status: open Ticket URL: https://rt.cpan.org/Ticket/Display.html?id=81172 Fixed in 0.52. Thank you for the report.
[rt.cpan.org #81094] Inline build fails using INSTALL_BASE
Wed Mar 06 21:15:25 2013: Request 81094 was acted upon. Transaction: Correspondence added by SISYPHUS Queue: Inline Subject: Inline build fails using INSTALL_BASE Broken in: 0.50, 0.51 Severity: Critical Owner: Nobody Requestors: c...@cpan.org Status: open Ticket URL: https://rt.cpan.org/Ticket/Display.html?id=81094 Fixed in 0.52 Thank you for the report
[rt.cpan.org #81375] chdir without cc
Tue Nov 27 06:37:04 2012: Request 81375 was acted upon.
Transaction: Correspondence added by SISYPHUS
Queue: Inline
Subject: chdir without cc
Broken in: 0.50
Severity: Normal
Owner: Nobody
Requestors: bernhard+c...@lsmod.de
Status: open
Ticket URL: https://rt.cpan.org/Ticket/Display.html?id=81375
On Mon Nov 26 21:03:00 2012, xyf.x...@gmail.com wrote:
I vote for David, It's a bug from chdir other than Inline.
File::chdir certainly provides an elegant solution to the problem, but
I'll stick with using the eval{} safety net, for the moment at least.
I'm not really all that keen to introduce a new dependency just to save
a couple of lines of code.
I do think it's an Inline::C bug.
Admittedly, it's a bit unusual to want to safeguard Inline::C code
against the absence of a C compiler (or of a missing make utility or of
uncompilable code, etc.), but I think one is entitled to do that. And if
one wants to do that by using eval{} (as the OP does), then one has
every right to expect that the script will return to the *original* cwd
if $@ gets set.
I think chdir() is behaving as it should. If we want to claim that it's
not an Inline::C bug, then we would have to argue that the OP is doing
something that's not allowed. (But of course, IMO, he isn't doing
anything wrong.)
Cheers,
Rob
[rt.cpan.org #81375] chdir without cc
Sat Nov 24 19:52:30 2012: Request 81375 was acted upon.
Transaction: Correspondence added by SISYPHUS
Queue: Inline
Subject: chdir without cc
Broken in: 0.50
Severity: Normal
Owner: Nobody
Requestors: bernhard+c...@lsmod.de
Status: open
Ticket URL: https://rt.cpan.org/Ticket/Display.html?id=81375
On Sat Nov 24 07:56:37 2012, bmwiedemann wrote:
I appended to your script:
system(pwd);
[snip]
Using Pure Perl Implementation
42
/home/bernhard/temp/_Inline/build/testc_pl_b91d
and it showed that it changed the current dir for the perl process
Yes, this could be fixed from within the script I provided as follows:
#
use strict;
use warnings;
use Cwd;
my $cwd = getcwd();
eval {
require Inline; Inline-import (C = Config =
#CC = 'bogus', # Easy way to make the build fail
BUILD_NOISY = 1);
require Inline; Inline-import (C =' EOC');
int foo() {
warn(Using Inline\n);
return 42;
}
EOC
};
# If Inline is unavailable, foo() simply calls
# the sub bar() pure perl implementation.
if($@) {
chdir $cwd or warn Couldn't chdir to $cwd;
*foo =\bar;
}
sub bar {
warn(Using Pure Perl Implementation\n);
return 42;
}
my $x = foo();
print $x\n;
print $cwd, \n;
#
(I've used Cwd::getcwd instead of the pwd system call because pwd is not
available on all systems.)
However, I think (not yet fully tested) this can also be fixed quite
simply from within C.pm by rewriting sub compile as:
#
sub compile {
my $o = shift;
my $build_dir = $o-{API}{build_dir};
my $cwd = cwd;
($cwd) = $cwd =~ /(.*)/ if $o-UNTAINT;
chdir $build_dir;
eval {
$o-call('makefile_pl', 'perl Makefile.PL', 2);
$o-call('make', 'make', 2);
$o-call('make_install', 'make install', 2);
};
chdir $cwd;
die if $@;
$o-call('cleanup', 'Cleaning Up', 2);
}
#
So I'll go with that changed version of C.pm's sub compile unless, in
the course of more thorough testing, I discover a problem with it.
If it tests ok for me, I'll release an Inline-0.51_03 that contains the
fix in a day or two.
Thanks for the report !
Cheers,
Rob
[rt.cpan.org #81375] chdir without cc
Fri Nov 23 20:17:08 2012: Request 81375 was acted upon.
Transaction: Correspondence added by SISYPHUS
Queue: Inline
Subject: chdir without cc
Broken in: 0.50
Severity: Normal
Owner: Nobody
Requestors: bernhard+c...@lsmod.de
Status: new
Ticket URL: https://rt.cpan.org/Ticket/Display.html?id=81375
On Fri Nov 23 07:52:45 2012, bmwiedemann wrote:
I used Inline C in eval
to make optional acceleration
and fallback to generic perl if unavailable,
but this failed when no gcc was installed,
because Inline would chdir to the _Inline/build/xxx_ dir
and remain there when the program started
This caused errors with modules in . not being found
and output files going to the wrong place.
Could you post a simple demo script ? I can't reproduce the problem.
I tried the following test script:
use strict;
use warnings;
eval {
require Inline; Inline-import (C = Config =
BUILD_NOISY = 1);
require Inline; Inline-import (C =' EOC');
int foo() {
warn(Using Inline\n);
return 42;
}
EOC
};
# If Inline is unavailable, foo() simply calls
# the sub bar() pure perl implementation.
if($@) {
*foo =\bar;
}
sub bar {
warn(Using Pure Perl Implementation\n);
return 42;
}
my $x = foo();
print $x\n;
If I hide cc (gcc.exe in my case), the build fails for that reason, and
the script falls back to the pure perl implementation (sub bar).
This is as it's meant to be, and as it should be.
Cheers,
Rob
[rt.cpan.org #81094] Inline build fails using INSTALL_BASE
Tue Nov 20 04:48:51 2012: Request 81094 was acted upon. Transaction: Correspondence added by SISYPHUS Queue: Inline Subject: Inline build fails using INSTALL_BASE Broken in: 0.50, 0.51 Severity: Critical Owner: Nobody Requestors: c...@cpan.org Status: open Ticket URL: https://rt.cpan.org/Ticket/Display.html?id=81094 On Sun Nov 11 16:39:50 2012, devel.chm...@gmail.com wrote: I did a clean Inline-0.51 install into a new location (which required Test::Warn, Sub::Uplevel to be installed and Carp to be updated) and the test still failed. Then after an install of ExtUtils::MakeMaker 6.62 Inline build and installed just fine. It looks like the problem is a bug in the earlier EU::MM and setting a higher minimum version for Inline to build seems reasonable to me. Inline-0.51_02 has been pushed to CPAN. PREREQ_PM for EU::MM now gets set to 6.62 - but only if INSTALL_BASE is specified on the command line, and only then if the current version of EU::MM =~ m/6\.57/ Cheers, Rob
[rt.cpan.org #81172] using Inline with = 'Event' fails to compile
Tue Nov 20 04:56:47 2012: Request 81172 was acted upon. Transaction: Correspondence added by SISYPHUS Queue: Inline Subject: using Inline with = 'Event' fails to compile Broken in: (no value) Severity: (no value) Owner: Nobody Requestors: peter.smoczyn...@i-new.com Status: open Ticket URL: https://rt.cpan.org/Ticket/Display.html?id=81172 On Mon Nov 19 06:39:21 2012, peter.smoczyn...@i-new.com wrote: since my comments in response to your last mail could easily be overlooked, here's the most important explicitly again.. thanx, Rob! peter So ... the space between the -I and the /opt doesn't cause any problems until the whole thing is enclosed in double-quotes ? (Please correct me if that's wrong.) yes, the space between the -I and the /opt does not cause any problems -- that is correct! might be reminiscent to the old kr days..? Inline-0.51_02, which contains the fix (substitution regex) I mentioned in my last post to this thread, has now been uploaded to CPAN. Cheers, Rob
[rt.cpan.org #81172] using Inline with = 'Event' fails to compile
Fri Nov 16 19:58:21 2012: Request 81172 was acted upon. Transaction: Correspondence added by SISYPHUS Queue: Inline Subject: using Inline with = 'Event' fails to compile Broken in: (no value) Severity: (no value) Owner: Nobody Requestors: peter.smoczyn...@i-new.com Status: open Ticket URL: https://rt.cpan.org/Ticket/Display.html?id=81172 On Fri Nov 16 06:51:09 2012, peter.smoczyn...@i-new.com wrote: in fact it's the space(!) and not the double quotes! i.e. -I /opt/perl5.12.2.debug/lib/site_perl/5.12.2/i86pc-solaris/Event vs. -I/opt/perl5.12.2.debug/lib/site_perl/5.12.2/i86pc-solaris/Event Well spotted - I had missed that there was a space stuck in there. So ... the space between the -I and the /opt doesn't cause any problems until the whole thing is enclosed in double-quotes ? (Please correct me if that's wrong.) I would have expected that space to be a problem even if there *weren't* any enclosing double-quotes. But, if that's not the case, then quote_space() probably needs to take this into consideration. I'm thinking quote_space() should be able to do this at the end of its processing with s/\-I\s+\//-I\//g since any spaces between the leading -I and the first / can never be meaningful (right ?). If you want to give that a try, at the end of the quote_space() subroutine in C.pm, change: my $out = join '', @in; $_[0] = $out; to: my $out = join '', @in; out =~ s/\-I\s+\//-I\//g; $_[0] = $out; I haven't tested, however, so I'm being a bit premature here ... There's also the case that -I /foo would be changed to -I /foo if it was the first element in the string, so that needs to be looked at, too. I'll release 0.51_01 in a couple of days time, and let you know when that happens. It will contain, among other things, a fix for this issue. Thanks for the report, and for the digging. Cheers, Rob
[rt.cpan.org #81172] using Inline with = 'Event' fails to compile
Thu Nov 15 20:53:44 2012: Request 81172 was acted upon. Transaction: Correspondence added by SISYPHUS Queue: Inline Subject: using Inline with = 'Event' fails to compile Broken in: (no value) Severity: (no value) Owner: Nobody Requestors: peter.smoczyn...@i-new.com Status: open Ticket URL: https://rt.cpan.org/Ticket/Display.html?id=81172 On Thu Nov 15 06:57:05 2012, peter.smoczyn...@i-new.com wrote: Hi Rob! here is the BUILD_NOISY output on version 0.48: Sun-A3 root 261/0 (~/peter/inline_fails_to_compile)# la total 4 -rw-r--r-- 1 root root 529 Nov 14 17:05 compile_test_1.t -rw-r--r-- 1 root root 581 Nov 15 10:47 compile_test_2.t Sun-A3 root 262/0 (~/peter/inline_fails_to_compile)# /opt/perl5.12.2.debug/bin/perl compile_test_2.t Starting Build Preprocess Stage Finished Build Preprocess Stage Starting Build Parse Stage Finished Build Parse Stage Starting Build Glue 1 Stage Finished Build Glue 1 Stage Starting Build Glue 2 Stage Finished Build Glue 2 Stage Starting Build Glue 3 Stage Finished Build Glue 3 Stage Starting Build Compile Stage Starting perl Makefile.PL Stage Writing Makefile for compile_test_2_t_a7b1 Finished perl Makefile.PL Stage Starting make Stage /opt/perl5.12.2.debug/bin/perl /opt/perl5.12.2.debug/lib/5.12.2/ExtUtils/xsubpp -typemap /opt/perl5.12.2.debug/lib/5.12.2/ExtUtils/typemap compile_test_2_t_a7b1.xs compile_test_2_t_a7b1.xsc mv compile_test_2_t_a7b1.xsc compile_test_2_t_a7b1.c gcc -c -I/root/peter/inline_fails_to_compile -I/usr/local/include -I/usr/local/BerkeleyDB.4.5/include -DDEBUGGING -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -DPERL_USE_SAFE_PUTENV -g -DVERSION=\0.00\ -DXS_VERSION=\0.00\ -fPIC -I/opt/perl5.12.2.debug/lib/5.12.2/i86pc-solaris/CORE compile_test_2_t_a7b1.c compile_test_2_t_a7b1.xs:5: error: expected ')' before '*' token make: *** [compile_test_2_t_a7b1.o] Error 1 This is a bit confusing. Firstly, the 0.48 build fails (though no mention of a missing EventAPI.h). Secondly, if the 0.48 build finds EventAPI.h, I don't see why the 0.51 build can't do the same. Neither of the 2 builds specify -I/opt/perl5.12.2.debug/lib/site_perl/5.12.2/i86pc-solaris/Event (which is the location of EventAPI.h). Cheers, Rob
[rt.cpan.org #81172] using Inline with = 'Event' fails to compile
Wed Nov 14 18:05:43 2012: Request 81172 was acted upon.
Transaction: Correspondence added by SISYPHUS
Queue: Inline
Subject: using Inline with = 'Event' fails to compile
Broken in: (no value)
Severity: (no value)
Owner: Nobody
Requestors: peter.smoczyn...@i-new.com
Status: new
Ticket URL: https://rt.cpan.org/Ticket/Display.html?id=81172
On Wed Nov 14 11:35:40 2012, peter.smoczyn...@i-new.com wrote:
#!/opt/perl5.12.2.debug/bin/perl
use strict;
use warnings;
use Inline with = 'Event';
use Inline C = Config =
BUILD_NOISY = 1;
use Inline C = 'EOC_EVDMP_EVENT_C';
void evdmp_event_c (pe_event * event)
{
char *classname = HvNAME(SvSTASH(SvRV(event-mysv)));
printf(evdmp_event_c()\ne type: %s\ne hits: %d\ne prio %d\n,
classname,
event-hits,
event-prio
);
if (strcmp(classname, (const char *) Event::Event::Io) == 0)
{
printf(e got: %u\n, ((pe_ioevent *) event)-got);
}
}
EOC_EVDMP_EVENT_C
exit 0;
Could you insert the BUILD_NOISY config option (as per above), and
then run the script with Inline-0.48.
Then post the output, so that I can compare it with the output you've
posted for the failing build.
Where is EventAPI.h located ?
For a quick workaround, I think you could add the location of
EventAPI.h to the CPATH environment variable:
export CPATH=$CPATH:/wherever/it/is
(At least that's how it vwould be done on linux. I assume solaris is
the same.)
Cheers,
Rob
[rt.cpan.org #81094] Inline build fails using INSTALL_BASE
Sun Nov 11 15:05:20 2012: Request 81094 was acted upon. Transaction: Correspondence added by SISYPHUS Queue: Inline Subject: Inline build fails using INSTALL_BASE Broken in: 0.50, 0.51 Severity: Critical Owner: Nobody Requestors: c...@cpan.org Status: open Ticket URL: https://rt.cpan.org/Ticket/Display.html?id=81094 On Sun Nov 11 11:31:44 2012, devel.chm...@gmail.com wrote: Hi Rob- Perhaps the problem is perl version specific as I have not had trouble building Inline with perl 5.10.x from cygwin. This build was with the latest cygwin perl 5.14.2. The good news is that since all this was installed in a separate location, I should be able to reproduce the bug using a different INSTALL_BASE. Of course, I need to get PDL up and running first but will follow up with the details when I can do so. --Chris I've just installed the latest cygwin-1.7.17 (perl-5.14.2) on a Windows 7 box, and then installed Inline-0.51 (and its dependency chain) into ~/modules by specifying INSTALL_BASE=~/modules. I still didn't strike the problem you reported - but I did something a little differently. When it came to installing Parse-RecDescent-1.967009, the Makefile.PL croaked because EU::MM was at version 6.57_05, but 6.62 was needed. Rather than opt for an earlier version of P::RD, I installed version 6.62 of EU::MM (also into ~/modules) and all then went fine. Having done that, I then re-jigged things to build Inline-0.51 (perl Makefile.PL INSTALL_BASE=~/elsewhere) using version 6.57_05 of EU::MM and got exactly the same problem as you did. Apparently that's the version of EU::MM that originally shipped with 5.14.0 ... I haven't checked which version of EU::MM shgipped with 5.14.2 ... is upgrading to a later version of EU::MM an acceptable solution to this problem ? Cheers, Rob
[rt.cpan.org #81094] Inline build fails using INSTALL_BASE
Sat Nov 10 22:47:45 2012: Request 81094 was acted upon. Transaction: Correspondence added by SISYPHUS Queue: Inline Subject: Inline build fails using INSTALL_BASE Broken in: 0.50, 0.51 Severity: Critical Owner: Nobody Requestors: c...@cpan.org Status: open Ticket URL: https://rt.cpan.org/Ticket/Display.html?id=81094 On Sat Nov 10 13:02:31 2012, CHM wrote: Installing /cygdrive/e/chm/pdl/try/Inline- 0.51/C/_Inline_test/lib/auto/_01syntax_t_6b3a/_01syntax_t_6b3a.bs Installing /cygdrive/e/chm/pdl/try/Inline- 0.51/C/_Inline_test/lib/auto/_01syntax_t_6b3a/_01syntax_t_6b3a.dll chmod 755 /usr/lib/perl5/site_perl/5.14/i686-cygwin-threads- 64int/auto/_01syntax_t_6b3a/_01syntax_t_6b3a.dll chmod: cannot access `/usr/lib/perl5/site_perl/5.14/i686-cygwin-threads- 64int/auto/_01syntax_t_6b3a/_01syntax_t_6b3a.dll': No such file or directory We see that _01syntax_t_6b3a.dll has been installed to the correct location - which, incidentally, is the same location to which it would have been installed even if INSTALL_BASE had *not* been specified. But then chmod goes beserk, and tries to chmod a _01syntax_t_6b3a.dll that's in a completely different (and non-exzistent) location. I tried building Inline-0.51 (with 'perl Makefile.PL INSTALL_BASE=C:/foo_bar'), on a native Win32 (MinGW) build of perl- 5.16.0, and it all went fine. (This was a perl that did not already have Inline installed.) On my Cygwin-1.7.7 installation (perl-5.10.1), I already had a build of Inline-0.49 that had been installed with INSTALL_BASE=~/modules so I removed it and built and installed Inline-0.51 (with 'perl Makefile.PL INSTALL_BASE=~/modules'). All went fine, except for that fork (rebase ?) issue, which is a completely different issue, and one that I can no longer be bothered with. So, I'm thinking we have some sort of Cygwin and/or EU::MM bug at play here - but it could also well be that Inline is the culprit. It's difficult for me to tell if I can't reproduce the error. It would bew interesting to see the original (troublesome) /cygdrive/e/chm/pdl/try/Inline- 0.51/C/_Inline_test/build/_01syntax_t_6b3a/Makefile if you still have it, or have the energy to reproduce it. Good that you found a workaround, though that doesn't make the bug any less annoying, of course. Cheers, Rob
[rt.cpan.org #67053] Space in pwd
Tue Oct 09 00:58:11 2012: Request 67053 was acted upon. Transaction: Correspondence added by SISYPHUS Queue: Inline Subject: Space in pwd Broken in: 0.48 Severity: Critical Owner: Nobody Requestors: rur...@x-ray.at Status: open Ticket URL: https://rt.cpan.org/Ticket/Display.html?id=67053 On Sun Apr 03 05:16:27 2011, SISYPHUS wrote: On Wed Mar 30 08:29:11 2011, rur...@x-ray.at wrote: Attached new patch fixed also the remaining C/t/07typemap_multi.t problem. The quote_space() subroutine that formed part of that patch has, as of Inline-0.50_03, been re-written as a result of https://rt.cpan.org/Ticket/Display.html?id=80026 Cheers, Rob
[rt.cpan.org #80026] LIB is being in correctly quoted when using more than one lib path
Tue Oct 09 00:37:15 2012: Request 80026 was acted upon. Transaction: Correspondence added by SISYPHUS Queue: Inline Subject: LIB is being in correctly quoted when using more than one lib path Broken in: 0.48, 0.48_01, 0.48_02, 0.49, 0.49_01, 0.49_02, 0.50, 0.50_01, 0.50_02 Severity: Important Owner: Nobody Requestors: jcleme...@cpan.org Status: open Ticket URL: https://rt.cpan.org/Ticket/Display.html?id=80026 On Sun Oct 07 11:39:06 2012, JCLEMENTS wrote: Thanks for getting this fixed so quickly. Well, the main thing is that it doesn't break things for those who don't have whitespace in their directory names just how well it works for those who *do* have whitespace in their directory names is not of great importance to me, personally. (I don't really see why they can't do the quoting themselves.) Anyway, as of Inline-0.50_03, which has just been uploaded to cpan, the quote_space() subroutine should now be doing the right thing pretty much across the board, afaik. If the INC config arg contains any tabs or doublequotes, then quote_space() won't alter it in any way - which will cause problems if that arg contains some whitespace that needs to be quoted. (This is the only shortcoming I'm aware of at the moment ... someone who cares about it can fix that aspect.) If no problems with Inline-0.50_03 become evident in the next few days, then it will be released as Inline-0.51 on the evening of Sat 13 Oct (Australian time). Cheers, Rob
[rt.cpan.org #75664] Fails 09parser test in Cygwin with *** fatal error
Thu Mar 15 06:20:05 2012: Request 75664 was acted upon. Transaction: Correspondence added by SISYPHUS Queue: Inline Subject: Fails 09parser test in Cygwin with *** fatal error Broken in: 0.50 Severity: Important Owner: Nobody Requestors: starrych...@oliveyou.net Status: open Ticket URL: https://rt.cpan.org/Ticket/Display.html?id=75664 On Wed Mar 14 08:03:46 2012, daoswald wrote: My suggestion is to document the issue in a future release of Inline I generally take the view that, if it's not an Inline issue, then there's no need to take any action at all. But this non-Inline issue is a little different - in that it's not immediately apparent that it has nothing to do with Inline. (At least, it wasn't to me ... and I was damn relieved when Chloe's follow up report appeared.) So, I think I'll do as you suggest and create some documentation about it in the Inline-FAQ. Not that anyone ever checks the Inline-FAQ ... but at least it would give us a ready-made link to which we can (indignantly ;-) refer future questioners about this problem. When that's done, I'll close this bug report - but I'll leave it open for the meantime. Thanks !! Cheers, Rob
[rt.cpan.org #75664] Fails 09parser test in Cygwin with *** fatal error
Wed Mar 14 04:13:11 2012: Request 75664 was acted upon. Transaction: Correspondence added by SISYPHUS Queue: Inline Subject: Fails 09parser test in Cygwin with *** fatal error Broken in: 0.50 Severity: Important Owner: Nobody Requestors: starrych...@oliveyou.net Status: open Ticket URL: https://rt.cpan.org/Ticket/Display.html?id=75664 On Wed Mar 14 02:34:10 2012, I updated some Cygwin packages, and then it gave me an error saying I needed to run rebaseall, which I've never seen before. I had to run it from only ash or dash, which I've never heard of before. I ran it, it did something, and then I tried to install Inline::C again and it worked this time. Thanks for that - good to know that 'rebaseall' fixes the problem. I can actually reproduce the problem on my Cygwin installation ... and I expect 'rebaseall' will fix the problem here, too, if I can just discover wtf one needs to do in order to successfully run that command. I keep getting an error which, in essence, tells me that I need to do exactly what I just did, in order to successfully run 'rebaseall'. Cheers, Rob
[rt.cpan.org #54825] Warnings During Build
URL: https://rt.cpan.org/Ticket/Display.html?id=54825
On Fri Jan 21 06:41:28 2011, JAWNSY wrote:
Reopening for a very quick question: have you considered using
Test::Warn? It will ensure the warnings are emitted, while at the same
time suppressing them from test output.
I guess it would be ok to suppress those taint-related warnings from
the test suite output (if we can find a satisfactory way of doing
that). One way would be to set the config option 'NO_UNTAINT_WARN =
1;' in the test script.
However, I'd rather *not* do that in case someone uses that test script
as a template, thereby running their scripts with 'NO_UNTAINT_WARN =
1;', totally oblivious to the sorts of things that Inline is doing
under the hood.
My attempts at using Test::Warn to detect and suppress the warnings
have not yet worked:
#
use warnings;
use strict;
use Test::More tests = 1;
use Test::Warn;
use Inline Config =
UNTAINT = 1,
DIRECTORY = '_Inline_test';
use Inline C = 'END_OF_C_CODE';
int add(int x, int y) {
return x + y;
}
END_OF_C_CODE
warnings_are {add(3,4)} [];
#
The warnings are issued during Inline's build phase, before the
warnings_are() test is run - so I get output of:
#
1..1
In Inline::env_untaint() : Blindly untainting tainted fields in %ENV.
In Inline::check_config_file(): Blindly untainting Inline configuration
file information.
In Inline::env_untaint() : Blindly untainting tainted fields in %ENV.
In Inline::obj_untaint() : Blindly untainting tainted fields in Inline
object.
ok 1
#
I'll keep looking at this (as time permits) until I either find a way
to make it work, or come to an understanding that it can't be made to
work.
Cheers,
Rob
[rt.cpan.org #54825] Warnings During Build
URL: https://rt.cpan.org/Ticket/Display.html?id=54825 Hi, The Subroutine Inline::C::get_parser redefined... warnings and associated diagnostic comments have gone, but the Blindly untaininting ... warnings are still there (as I believe it's important that Inline tells us that it's doing these things). During the running of the test suite these warnings are, however, now pre-announced with the message: Expect a number of Blindly untainting ... warnings - these are intended. So I'm now closing this ticket. But check out Inline-0.47 (uploaded to CPAN today) and see what you think. If you require further action on this (or would simply prefer that the ticket remain open), please feel free to re-open it. (I think you can do that by simply updating this ticket ... not sure :-) Cheers, Rob
[rt.cpan.org #55543] Inline::C can crash the perl interpreter if function uses PUSHMARK
URL: https://rt.cpan.org/Ticket/Display.html?id=55543
On Sat Mar 13 23:27:29 2010, asuffi...@suffields.me.uk wrote:
Inline::C uses this hack in an attempt to detect the difference
between void returns and XSUB list returns:
temp = PL_markstack_ptr++;
$function($arg_name_list);
if (PL_markstack_ptr != temp) {
/* truly void, because dXSARGS not invoked */
PL_markstack_ptr = temp;
XSRETURN_EMPTY; /* return empty stack */
}
/* must have used dXSARGS; list context implied */
return; /* assume stack size is correct */
Sadly, this does not work. If the mark stack is reallocated (due to
use of PUSHMARK in any function called), then PL_markstack_ptr can
have a completely different value. This code then scribbles over it
with the old value, pointing to freed memory; the interpreter will
crash shortly after this.
I haven't checked carefully, but I think this should have been
examining the value of (PL_markstack_ptr - PL_markstack) instead -
that's the current height of the stack, rather than its current
address.
(cc'ing the Inline mailing list in case anyone there is interested.)
Wow ... that code has been around for ages.
I think I get the picture, though I'm currently having trouble
reproducing the bug from the description. (Dimness on my part, one
suspects :-)
Do you have a simple demo script ? It doesn't have to do anything
meaningful - just something that demonstrates the problem.
Thanks for the report !
Cheers,
Rob
[rt.cpan.org #54825] Warnings During Build
URL: https://rt.cpan.org/Ticket/Display.html?id=54825
On Sat Feb 20 14:01:05 2010, JAWNSY wrote:
Hi there,
While trying to build the latest version of Inline for Debian (where
it
is packaged as libinline-perl), I encountered several warnings and
suspicious diagnostic output during testing. As far as I can tell from
the toolchain output, there were no dependencies missing during build.
What follows is the test output:
dh_auto_test
make[1]: Entering directory
`/build/jon-libinline-perl_0.46-1-i386-lJq_CL/libinline-perl-0.46'
make[2]: Entering directory
`/build/jon-libinline-perl_0.46-1-i386-lJq_CL/libinline-perl-0.46/C'
make[2]: Leaving directory
`/build/jon-libinline-perl_0.46-1-i386-lJq_CL/libinline-perl-0.46/C'
PERL_DL_NONLAZY=1 /usr/bin/perl -MExtUtils::Command::MM -e
test_harness(0, 'blib/lib', 'blib/arch') t/*.t
t/00init.t ok
t/01usages.t .. ok
t/02config.t .. ok
t/03errors.t .. ok
t/04create.t .. ok
t/05files.t ... skipped: (no reason given)
All tests successful.
Files=6, Tests=14, 11 wallclock secs ( 0.04 usr 0.02 sys + 0.50
cusr
0.10 csys = 0.66 CPU)
Result: PASS
make[2]: Entering directory
`/build/jon-libinline-perl_0.46-1-i386-lJq_CL/libinline-perl-0.46/C'
PERL_DL_NONLAZY=1 /usr/bin/perl -MExtUtils::Command::MM -e
test_harness(0, '../blib/lib', '../blib/arch') t/*.t
t/00init.t ... ok
t/01syntax.t . ok
t/02config.t . ok
t/03typemap.t ok
t/04perlapi.t ok
t/05xsmode.t . ok
Subroutine Inline::C::get_parser redefined at ../blib/lib/Inline.pm
line
312 (#1)
(W redefine) You redefined a subroutine. To suppress this
warning, say
{
no warnings 'redefine';
eval sub name { ... };
}
t/06parseregexp.t ok
Subroutine Inline::C::get_parser redefined at ../blib/lib/Inline.pm
line
312 (#1)
(W redefine) You redefined a subroutine. To suppress this
warning, say
{
no warnings 'redefine';
eval sub name { ... };
}
t/07typemap_multi.t .. ok
In Inline::env_untaint() : Blindly untainting tainted fields in %ENV.
In Inline::env_untaint() : Blindly untainting tainted fields in %ENV.
In Inline::obj_untaint() : Blindly untainting tainted fields in Inline
object.
In Inline::env_untaint() : Blindly untainting tainted fields in %ENV.
In Inline::env_untaint() : Blindly untainting tainted fields in %ENV.
In Inline::obj_untaint() : Blindly untainting tainted fields in Inline
object.
In Inline::env_untaint() : Blindly untainting tainted fields in %ENV.
In Inline::env_untaint() : Blindly untainting tainted fields in %ENV.
In Inline::obj_untaint() : Blindly untainting tainted fields in Inline
object.
In Inline::env_untaint() : Blindly untainting tainted fields in %ENV.
In Inline::env_untaint() : Blindly untainting tainted fields in %ENV.
In Inline::obj_untaint() : Blindly untainting tainted fields in Inline
object.
t/08taint.t .. ok
All tests successful.
Files=9, Tests=21, 13 wallclock secs ( 0.02 usr 0.02 sys + 9.50
cusr
3.24 csys = 12.78 CPU)
Result: PASS
This regression appears to have been introduced in version 0.46;
rebuilding 0.45 with the most recent perl and other dependencies
yields
the following test output:
dh_auto_test
make[1]: Entering directory
`/build/jon-libinline-perl_0.45-1-i386-dvYTxJ/libinline-perl-0.45'
make[2]: Entering directory
`/build/jon-libinline-perl_0.45-1-i386-dvYTxJ/libinline-perl-0.45/C'
make[2]: Leaving directory
`/build/jon-libinline-perl_0.45-1-i386-dvYTxJ/libinline-perl-0.45/C'
PERL_DL_NONLAZY=1 /usr/bin/perl -MExtUtils::Command::MM -e
test_harness(0, 'blib/lib', 'blib/arch') t/*.t
t/00init.t ok
t/01usages.t .. ok
t/02config.t .. ok
t/03errors.t .. ok
t/04create.t .. ok
t/05files.t ... skipped: (no reason given)
All tests successful.
Files=6, Tests=14, 10 wallclock secs ( 0.04 usr 0.02 sys + 0.56
cusr
0.06 csys = 0.68 CPU)
Result: PASS
make[2]: Entering directory
`/build/jon-libinline-perl_0.45-1-i386-dvYTxJ/libinline-perl-0.45/C'
PERL_DL_NONLAZY=1 /usr/bin/perl -MExtUtils::Command::MM -e
test_harness(0, '../blib/lib', '../blib/arch') t/*.t
t/00init.t ... ok
t/01syntax.t . ok
t/02config.t . ok
t/03typemap.t ok
t/04perlapi.t ok
t/05xsmode.t . ok
t/06parseregexp.t ok
t/07typemap_multi.t .. ok
All tests successful.
Files=8, Tests=16, 10 wallclock secs ( 0.04 usr 0.02 sys + 7.00
cusr
2.48 csys = 9.54 CPU)
Result: PASS
The suspicious diagnostic output is just the standard use
diagnostics; ouptut - assuming I've correctly identified the output
you're referring to :-)
The redefinition warnings come about as a result of fixing #49669:
https://rt.cpan.org/Public/Bug/Display.html?id=49669
Basically, I think we could silence the warnings in one of 2 ways:
1) Fix #49669 in such a way that get_parser() does not get redefined;
2) Take
