Skip Menu |

Preferred bug tracker

Please visit the preferred bug tracker to report your issue.

This queue is for tickets about the Inline CPAN distribution.

Report information
The Basics
Id: 65703
Status: resolved
Priority: 0/
Queue: Inline
People
Owner: Nobody in particular
Requestors: alexander.haeckel [...] web.de
Cc: jquelin [...] cpan.org
AdminCc:
Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: (no value)

History Show all quoted text
  Sun Feb 13 17:31:29 2011 alexander.haeckel [...] web.de - Ticket created
Subject: Build Problem - Inline::C fails at t/08taint.t
Date: Sun, 13 Feb 2011 22:42:32 +0100
To: bug-Inline [...] rt.cpan.org
From: Alexander Haeckel <alexanderhaeckel [...] lavabit.com>
Hi, when building Inline-0.47 I get this message (PERL_INLINE_BUILD_NOISY=1): ,---- | t/08taint.t ............. Expect a number of "Blindly untainting ..." warnings - these are intended. | 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. | Can't exec "make": Datei oder Verzeichnis nicht gefunden at | ../blib/lib/Inline/C.pm line 794 (#1) | (W exec) A system(), exec(), or piped open call could not execute the | named program for the indicated reason. Typical reasons include: the | permissions were wrong on the file, the file wasn't found in | $ENV{PATH}, the executable in question was compiled for another | architecture, or the #! line in a script points to an interpreter that | can't be run for similar reasons. (Or maybe your system doesn't support | #! at all.) | | Uncaught exception from user code: | | A problem was encountered while attempting to compile and install your Inline | C code. The command that failed was: | make | | The build directory was: | /tmp/Inline-0.47/C/_Inline_test/build/_08taint_t_6b3a | | To debug the problem, cd to the build directory, and inspect the output files. | | at t/08taint.t line 33 | BEGIN failed--compilation aborted at t/08taint.t line 42. | at t/08taint.t line 42 | One or more DATA sections were not processed by Inline. | | t/08taint.t ............. Dubious, test returned 2 (wstat 512, 0x200) | Failed 5/5 subtests `---- Of course I have "make" at "/usr/bin/make" in $PATH. $ perl -V ,---- | Summary of my perl5 (revision 5 version 12 subversion 3) configuration: | | Platform: | osname=linux, osvers=2.6.26-2-amd64, archname=x86_64-linux | uname='linux tentakel 2.6.26-2-amd64 #1 smp tue jan 25 05:59:43 utc 2011 x86_64 gnulinux ' | config_args='-de -Dprefix=/home/user1/perl5/perlbrew/perls/perl-512.3' | hint=recommended, useposix=true, d_sigaction=define | useithreads=undef, usemultiplicity=undef | useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef | use64bitint=define, use64bitall=define, uselongdouble=undef | usemymalloc=n, bincompat5005=undef | Compiler: | cc='cc', ccflags ='-fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include -D_LARGEFILE_SOURCE | -D_FILE_OFFSET_BITS=64', | optimize='-O2', | cppflags='-fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include' | ccversion='', gccversion='4.3.2', gccosandvers='' | intsize=4, longsize=8, ptrsize=8, doublesize=8, byteorder=12345678 | d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16 | ivtype='long', ivsize=8, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8 | alignbytes=8, prototype=define | Linker and Libraries: | ld='cc', ldflags =' -fstack-protector -L/usr/local/lib' | libpth=/usr/local/lib /lib /usr/lib /lib64 /usr/lib64 /usr/local/lib64 | libs=-lnsl -lgdbm -ldb -ldl -lm -lcrypt -lutil -lc -lgdbm_compat | perllibs=-lnsl -ldl -lm -lcrypt -lutil -lc | libc=/lib/libc-2.7.so, so=so, useshrplib=false, libperl=libperl.a | gnulibc_version='2.7' | Dynamic Linking: | dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E' | cccdlflags='-fPIC', lddlflags='-shared -O2 -L/usr/local/lib -fstack-protector' | | | Characteristics of this binary (from libperl): | Compile-time options: PERL_DONT_CREATE_GVSV PERL_MALLOC_WRAP USE_64_BIT_ALL | USE_64_BIT_INT USE_LARGE_FILES USE_PERLIO | USE_PERL_ATOF | Built under linux | Compiled at Feb 13 2011 02:11:11 | %ENV: | PERL6HOME="/home/user1/download/src/perl6/rakudo/parrot_install" | PERLBREW_PATH="/home/user1/perl5/perlbrew/bin:/home/user1/perl5/perlbrew/perls/perl-5.12.3/bin" | PERLBREW_PERL="perl-5.12.3" | PERLBREW_ROOT="/home/user1/perl5/perlbrew" | PERLBREW_VERSION="0.15" | PERL_INLINE_BUILD_NOISY="1" | @INC: | /home/user1/perl5/perlbrew/perls/perl-5.12.3/lib/site_perl/5.12.3/x86_64-linux | /home/user1/perl5/perlbrew/perls/perl-5.12.3/lib/site_perl/5.12.3 | /home/user1/perl5/perlbrew/perls/perl-5.12.3/lib/5.12.3/x86_64-linux | /home/user1/perl5/perlbrew/perls/perl-5.12.3/lib/5.12.3 `---- Thanks for your help, Alexander Haeckel -- "I can't understand why people are frightened of new ideas. I'm frightened of the old ones.” - John Cage
  Tue Feb 15 06:54:10 2011 sisyphus [...] cpan.org - Correspondence added
RT-Send-CC: alexanderhaeckel [...] lavabit.com
On Sun Feb 13 17:31:29 2011, alexander.haeckel@web.de wrote: Show quoted text
> > Of course I have "make" at "/usr/bin/make" in $PATH. >
In Inline.pm (in sub env_untaint) you'll find: $ENV{PATH} = $^O eq 'MSWin32' ? join ';', grep {not /^\./ and -d $_ } split /;/, $ENV{PATH} : join ':', grep {not /^\./ and -d $_ and not ((stat($_))[2] & 0022) } split /:/, $ENV{PATH}; Is that where /usr/bin/make gets removed from the path ? I don't know. I've seen reports of it having happened before - though only rarely, and not recently. It's not something I can reproduce on my linux box; nor have any of the cpan-testers who have tested 0.47 or 0.47_02 come across the problem (afaik). So we first need to identify the code that's causing it to happen, understand *why* that code is causing it to happen, and then work aout what to do about it. If you're not going run in taint mode then, of course, this failure can be ignored. It would, however, be nice to remove this bug - even better if that can be done without making Inline's behaviour regarding untainting even more dubious than it already is. Thanks for reporting this bug - and for any insights you can provide regarding what's causing it. Maybe start by replacing the above mentioned: join ':', grep {not /^\./ and -d $_ and not ((stat($_))[2] & 0022) } split /:/, $ENV{PATH}; with: join ':', grep {not /^\./ and -d $_ } split /:/, $ENV{PATH}; Then rebuild from scratch (or run 'make realclean') before re-building, and see if that makes any difference. Cheers, Rob
  Tue Feb 15 06:54:11 2011 The RT System itself - Status changed from 'new' to 'open'
  Tue Feb 15 16:18:12 2011 alexander.haeckel [...] web.de - Correspondence added
Subject: Re: [rt.cpan.org #65703] Build Problem - Inline::C fails at t/08taint.t
Date: Tue, 15 Feb 2011 22:17:52 +0100
To: bug-Inline [...] rt.cpan.org
From: Alexander Haeckel <alexanderhaeckel [...] lavabit.com>
Hi Rob, thank you very much for your quick reply. I looked into that and you were exactly right: join ':', grep {not /^\./ and -d $_ #this is the offending code -> and not ((stat($_))[2] & 0022) } split /:/, $ENV{PATH}; Because I gave write permission to group "adm" for "/usr/bin", "/usr/local/bin", etc these directories are removed from the path. I hope that's helpful to you, Alexander Sisyphus via RT <bug-Inline@rt.cpan.org> writes: Show quoted text
> <URL: https://rt.cpan.org/Ticket/Display.html?id=65703 > > On Sun Feb 13 17:31:29 2011, alexander.haeckel@web.de wrote:
Show quoted text
>> >> Of course I have "make" at "/usr/bin/make" in $PATH. >>
Show quoted text
> In Inline.pm (in sub env_untaint) you'll find:
Show quoted text
> $ENV{PATH} = $^O eq 'MSWin32' ? > join ';', grep {not /^\./ and -d $_ > } split /;/, $ENV{PATH} > : join ':', grep {not /^\./ and -d $_ and > not ((stat($_))[2] & 0022) > } split /:/, $ENV{PATH};
Show quoted text
> Is that where /usr/bin/make gets removed from the path ? I don't know. > I've seen reports of it having happened before - though only rarely, > and not recently. It's not something I can reproduce on my linux box; > nor have any of the cpan-testers who have tested 0.47 or 0.47_02 come > across the problem (afaik).
Show quoted text
> So we first need to identify the code that's causing it to happen, > understand *why* that code is causing it to happen, and then work aout > what to do about it.
Show quoted text
> If you're not going run in taint mode then, of course, this failure > can be ignored. It would, however, be nice to remove this bug - even > better if that can be done without making Inline's behaviour regarding > untainting even more dubious than it already is.
Show quoted text
> Thanks for reporting this bug - and for any insights you can provide > regarding what's causing it.
Show quoted text
> Maybe start by replacing the above mentioned:
Show quoted text
> join ':', grep {not /^\./ and -d $_ and > not ((stat($_))[2] & 0022) > } split /:/, $ENV{PATH};
Show quoted text
> with:
Show quoted text
> join ':', grep {not /^\./ and -d $_ > } split /:/, $ENV{PATH};
Show quoted text
> Then rebuild from scratch (or run 'make realclean') before > re-building, and see if that makes any difference.
Show quoted text
> Cheers, Rob
Show quoted text
> ____________________________________________________________________________________ > Use the link below to report this message as spam. > https://lavabit.com/apps/teacher?sig=1689256&key=1111163831 > ____________________________________________________________________________________
-- "I can't understand why people are frightened of new ideas. I'm frightened of the old ones.” - John Cage
  Tue Feb 15 18:35:39 2011 sisyphus [...] cpan.org - Correspondence added
RT-Send-CC: alexanderhaeckel [...] lavabit.com
On Tue Feb 15 16:18:12 2011, alexander.haeckel@web.de wrote: Show quoted text
> Because I gave write permission to group "adm" for "/usr/bin", > "/usr/local/bin", etc these directories > are removed from the path. > > I hope that's helpful to you,
Yes, it certainly is helpful. We could construct Inline so that /usr/bin and /usr/local/bin are not removed from the path, even if they are writable. But I think that would defeat the purpose of running with the -T switch. Seems to me that, in your case, the t/08taint.t test script should be skipped completely, with a message telling you that you *cannot* use -T with Inline::C because '/usr/bin' is writable. Is that the right action to take ? I'd hate to be told by someone that "I ran an Inline::C script, and /usr/bin got wiped, even though I was running under the -T switch". There are plenty of warnings about my reservations regarding the use of -T with Inline::C ... but that's still *one* message I'd rather not receive :-) I would envisage using something like the following code to determine whether /usr/bin and/or /usr/local/bin are writable: ################################# if( (stat("/usr/bin"))[2] & 0022 ) { print "Tests skipped - you can't run with -T switch as '/usr/bin' is writable\n"; } if( (stat("/usr/local/bin"))[2] & 0022 ) { print "Tests skipped - you can't run with -T switch as '/usr/local/bin' is writable\n"; } ################################# Could you run that and check that it performs as intended ? Cheers, Rob
  Tue Feb 15 20:05:27 2011 alexander.haeckel [...] web.de - Correspondence added
Subject: Re: [rt.cpan.org #65703] Build Problem - Inline::C fails at t/08taint.t
Date: Wed, 16 Feb 2011 02:04:41 +0100
To: bug-Inline [...] rt.cpan.org
From: Alexander Haeckel <alexanderhaeckel [...] lavabit.com>
The problem here as I see it ist the use of (stat("/usr/bin"))[2] & 0022 instead of (stat("/usr/bin"))[2] & 0002 , because you must be authorized to write into the first case, but needn't be in the second. If you exclude 0020 you could exclude 0200 for the same reasons. To me it would seem more consistent to use the -w, -W operators to check for every directory in the path if it is writable at all. Then you can omit the (stat("/usr/bin"))[2] & 0??? test completely and just write: join ':', grep {not /^\./ and -d $_ and not -w $_ || -W $_ } split /:/, $ENV{PATH}; I hope this makes some sense to you. Alexander Sisyphus via RT <bug-Inline@rt.cpan.org> writes: Show quoted text
> <URL: https://rt.cpan.org/Ticket/Display.html?id=65703 > > On Tue Feb 15 16:18:12 2011, alexander.haeckel@web.de wrote:
Show quoted text
>> Because I gave write permission to group "adm" for "/usr/bin", >> "/usr/local/bin", etc these directories are removed from the path. >> >> I hope that's helpful to you,
Show quoted text
> Yes, it certainly is helpful.
Show quoted text
> We could construct Inline so that /usr/bin and /usr/local/bin are not > removed from the path, even if they are writable. But I think that > would defeat the purpose of running with the -T switch.
Show quoted text
> Seems to me that, in your case, the t/08taint.t test script should be > skipped completely, with a message telling you that you *cannot* use > -T with Inline::C because '/usr/bin' is writable.
Show quoted text
> Is that the right action to take ?
Show quoted text
> I'd hate to be told by someone that "I ran an Inline::C script, and > /usr/bin got wiped, even though I was running under the -T switch". > There are plenty of warnings about my reservations regarding the use > of -T with Inline::C ... but that's still *one* message I'd rather not > receive :-)
Show quoted text
> I would envisage using something like the following code to determine > whether /usr/bin and/or /usr/local/bin are writable:
Show quoted text
> ################################# > if( (stat("/usr/bin"))[2] & 0022 ) { > print "Tests skipped - you can't run with -T switch as '/usr/bin' is > writable\n"; > }
Show quoted text
> if( (stat("/usr/local/bin"))[2] & 0022 ) { > print "Tests skipped - you can't run with -T switch > as '/usr/local/bin' is writable\n"; > } > #################################
Show quoted text
> Could you run that and check that it performs as intended ?
Show quoted text
> Cheers, Rob
Show quoted text
> ____________________________________________________________________________________ > Use the link below to report this message as spam. > https://lavabit.com/apps/teacher?sig=1690966&key=1802200634 > ____________________________________________________________________________________
-- "I can't understand why people are frightened of new ideas. I'm frightened of the old ones.” - John Cage
  Tue Feb 15 20:20:52 2011 alexander.haeckel [...] web.de - Correspondence added
Subject: Re: [rt.cpan.org #65703] Build Problem - Inline::C fails at t/08taint.t
Date: Wed, 16 Feb 2011 02:20:27 +0100
To: bug-Inline [...] rt.cpan.org
From: Alexander Haeckel <alexanderhaeckel [...] lavabit.com>
The problem here as I see it ist the use of (stat("/usr/bin"))[2] & 0022 instead of (stat("/usr/bin"))[2] & 0002 , because you must be authorized to write into the first case, but needn't be in the second. If you exclude 0020 you could exclude 0200 for the same reasons. To me it would seem more consistent to use the -w, -W operators to check for every directory in the path if it is writable at all. Additionally it makes sense to test with -o, -O for if the directory belongs to the user to prevent "chmod-attacks". Then you can omit the (stat("/usr/bin"))[2] & 0??? test completely and just write: join ':', grep {not /^\./ and -d $_ and not -w $_ || -W $_ || -o $_ || -O $_ } split /:/, $ENV{PATH}; I hope this makes some sense to you. Alexander Sisyphus via RT <bug-Inline@rt.cpan.org> writes: Show quoted text
> <URL: https://rt.cpan.org/Ticket/Display.html?id=65703 > > On Tue Feb 15 16:18:12 2011, alexander.haeckel@web.de wrote:
Show quoted text
>> Because I gave write permission to group "adm" for "/usr/bin", >> "/usr/local/bin", etc these directories are removed from the path. >> >> I hope that's helpful to you,
Show quoted text
> Yes, it certainly is helpful.
Show quoted text
> We could construct Inline so that /usr/bin and /usr/local/bin are not > removed from the path, even if they are writable. But I think that > would defeat the purpose of running with the -T switch.
Show quoted text
> Seems to me that, in your case, the t/08taint.t test script should be > skipped completely, with a message telling you that you *cannot* use > -T with Inline::C because '/usr/bin' is writable.
Show quoted text
> Is that the right action to take ?
Show quoted text
> I'd hate to be told by someone that "I ran an Inline::C script, and > /usr/bin got wiped, even though I was running under the -T switch". > There are plenty of warnings about my reservations regarding the use > of -T with Inline::C ... but that's still *one* message I'd rather not > receive :-)
Show quoted text
> I would envisage using something like the following code to determine > whether /usr/bin and/or /usr/local/bin are writable:
Show quoted text
> ################################# > if( (stat("/usr/bin"))[2] & 0022 ) { > print "Tests skipped - you can't run with -T switch as '/usr/bin' is > writable\n"; > }
Show quoted text
> if( (stat("/usr/local/bin"))[2] & 0022 ) { > print "Tests skipped - you can't run with -T switch > as '/usr/local/bin' is writable\n"; > } > #################################
Show quoted text
> Could you run that and check that it performs as intended ?
Show quoted text
> Cheers, Rob
-- "I can't understand why people are frightened of new ideas. I'm frightened of the old ones.” - John Cage
  Fri Mar 25 05:08:12 2011 jquelin [...] cpan.org - Correspondence added
i get the same error: ================ A problem was encountered while attempting to compile and install your Inline C code. The command that failed was: make > out.make 2>&1 The build directory was: /home/jquelin/rpm/cauldron/perl-Inline/BUILD/Inline-0.48/C/_Inline_test/build/_08taint_1_p_0965 To debug the problem, cd to the build directory, and inspect the output files. at ./t/08taint_1.p line 7 BEGIN failed--compilation aborted at ./t/08taint_1.p line 13. Compilation failed in require at t/08taint.t line 30. # Looks like you planned 10 tests but ran 1. # Looks like your test exited with 2 just after 1. ================ but /usr/bin is not writable: $ which make /usr/bin/make $ ll -d /usr/bin/make -rwxr-xr-x 1 root root 174328 janv. 22 16:59 /usr/bin/make* $ perl -E 'say ( (stat("/usr/bin"))[2] & 0022 )' 0 but the problem should be similar, since running make manually works fine: ================ $ cd /home/jquelin/rpm/cauldron/perl-Inline/BUILD/Inline-0.48/C/_Inline_test/build/_08taint_1_p_0965 $ make /usr/bin/perl5.12.3 /usr/lib/perl5/vendor_perl/5.12.3/ExtUtils/xsubpp -typemap /usr/lib/perl5/5.12.3/ExtUtils/typemap _08taint_1_p_0965.xs > _08taint_1_p_0965.xsc && mv _08taint_1_p_0965.xsc _08taint_1_p_0965.c x86_64-mageia-linux-gnu-gcc -c -D_REENTRANT -D_GNU_SOURCE -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O2 -g -pipe -Wformat -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fstack-protector --param=ssp-buffer-size=4 -DVERSION=\"0.00\" -DXS_VERSION=\"0.00\" -fPIC "-I/usr/lib/perl5/5.12.3/x86_64-linux-thread-multi/CORE" _08taint_1_p_0965.c Running Mkbootstrap for _08taint_1_p_0965 () chmod 644 _08taint_1_p_0965.bs rm -f blib/arch/auto/_08taint_1_p_0965/_08taint_1_p_0965.so x86_64-mageia-linux-gnu-gcc -shared -O2 -g -pipe -Wformat -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fstack-protector --param=ssp-buffer-size=4 -L/usr/local/lib64 _08taint_1_p_0965.o -o blib/arch/auto/_08taint_1_p_0965/_08taint_1_p_0965.so \ \ chmod 755 blib/arch/auto/_08taint_1_p_0965/_08taint_1_p_0965.so cp _08taint_1_p_0965.bs blib/arch/auto/_08taint_1_p_0965/_08taint_1_p_0965.bs chmod 644 blib/arch/auto/_08taint_1_p_0965/_08taint_1_p_0965.bs ================
  Fri Mar 25 05:08:40 2011 jquelin [...] cpan.org - Cc JQUELIN added
  Sun Feb 23 13:10:55 2014 fraserbn [...] gmail.com - Correspondence added
From: fraserbn [...] gmail.com
On Tue Feb 15 20:05:27 2011, alexander.haeckel@web.de wrote: Show quoted text
> The problem here as I see it ist the use of > (stat("/usr/bin"))[2] & 0022 > instead of > (stat("/usr/bin"))[2] & 0002 > , because you must be authorized to write into > the first case, but needn't be in the second. > If you exclude 0020 you could exclude 0200 for > the same reasons. > To me it would seem more consistent to use the -w, -W operators > to check for every directory in the path if it > is writable at all. Then you can omit the > (stat("/usr/bin"))[2] & 0??? test completely and just write: > > join ':', grep {not /^\./ and -d $_ and not -w $_ || -W $_ > } split /:/, $ENV{PATH};
This issue just bit me when smoking CPAN on Android. Unfortunately, the above solution doesn't work for me. tl;dr: Skipping the tests when $^O eq 'android' would probably be for the best, if that filter is going to stay. Android's an interesting case. It's basically a linux system that doesn't provide any toolchain whatsoever, so you either have to install one yourself (and to do that, you need to root your phone and probably create/mount an ext3/4 partition in your sdcard) or have an app install it for you. Either way, the toolchain ends up in a non-standard location with non-standard permissions, and to use it you need to tweak with it's permissions and/or be root. There's probably no ideal solution here, but either way my suggestion is to have the module skip t/08taint.t under Android, and then to have env_untaint actually check if an entry is already untainted (with Scalar::Util::tainted in perl>=5.8, and whatever the eval invocation in older perls is); if it is, trust it as-is, no need to filter anything. That way, if someone wants to use Inline on Android under taint, they can do it by manually untainting $ENV{PATH}, which they should've been doing on the first place :)
  Wed Mar 05 08:39:01 2014 sisyphus1 [...] optusnet.com.au - Correspondence added
Subject: Re: [rt.cpan.org #65703] Build Problem - Inline::C fails at t/08taint.t
Date: Thu, 6 Mar 2014 00:37:43 +1100
To: <bug-Inline [...] rt.cpan.org>, <inline [...] perl.org>
From: <sisyphus1 [...] optusnet.com.au>
Show quoted text
-----Original Message----- From: Brian Fraser via RT
>> To me it would seem more consistent to use the -w, -W operators >> to check for every directory in the path if it >> is writable at all. Then you can omit the >> (stat("/usr/bin"))[2] & 0??? test completely and just write: >> >> join ':', grep {not /^\./ and -d $_ and not -w $_ || -W $_ >> } split /:/, $ENV{PATH};
> > This issue just bit me when smoking CPAN on Android. Unfortunately, the > above solution doesn't work for me. > > tl;dr: Skipping the tests when $^O eq 'android' would probably be for the > best, if that filter is going to stay.
I've just uploaded Inline-0.53_01 to CPAN. It includes Alexander's recommended change to env_untaint() and also has 08taint.t skip the tests for Android. Brian/Alexander - if you want any additional changes to env_untaint (or anything else, for that matter) just send me the patch and we should be able to get it incorporated into the next stable release (0.54). Thanks guys. Cheers, Rob
  Wed Apr 30 05:11:58 2014 PLICEASE [...] cpan.org - Correspondence added
I got this (I believe related) error trying to install Inline (+Inline::C) t/08taint.t ............. 1/10 Running Mkbootstrap for _08taint_1_p_0965 () chmod 644 _08taint_1_p_0965.bs /home/ollisg/perl5/perlbrew/perls/perl-5.18.2c/bin/perl /home/ollisg/.perlbrew/libs/perl-5.18.2c@dev/lib/perl5/ExtUtils/xsubpp -typemap "/home/ollisg/perl5/perlbrew/perls/perl-5.18.2c/lib/5.18.2/ExtUtils/typemap" _08taint_1_p_0965.xs > _08taint_1_p_0965.xsc && mv _08taint_1_p_0965.xsc _08taint_1_p_0965.c clang -c -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O2 -DVERSION=\"0.00\" -DXS_VERSION=\"0.00\" -fPIC "-I/home/ollisg/perl5/perlbrew/perls/perl-5.18.2c/lib/5.18.2/x86_64-linux/CORE" _08taint_1_p_0965.c /bin/sh: 1: clang: not found make: *** [_08taint_1_p_0965.o] Error 127 A problem was encountered while attempting to compile and install your Inline C code. The command that failed was: make > out.make 2>&1 The build directory was: /home/ollisg/.cpanm/work/1398847813.20092/Inline-0.55/C/_Inline_test/build/_08taint_1_p_0965 To debug the problem, cd to the build directory, and inspect the output files. at ./t/08taint_1.p line 7. ...propagated at /home/ollisg/.perlbrew/libs/perl-5.18.2c@dev/lib/perl5/Inline/C.pm line 797. BEGIN failed--compilation aborted at ./t/08taint_1.p line 7. Compilation failed in require at t/08taint.t line 45. # Looks like you planned 10 tests but ran 1. # Looks like your test exited with 2 just after 1. t/08taint.t ............. Dubious, test returned 2 (wstat 512, 0x200) Failed 9/10 subtests I've installed clang into my home directory because the version that comes with my OS is very old. I feel like this configuration should be supported, but perhaps not? As a work around I chmod -R -x the appropriate directorys in my clang install and the then install worked.
  Tue May 06 09:14:24 2014 chm [...] cpan.org - Correspondence added
I hit the same error with my cygwin64.  In my specific
case, the issue is that I have all of the added perl
modules installed into a separate non-system location
and PERL5LIB is set so that works.

With -T PERL5LIB is not consulted.  A look at the pod
for taint in perlrun suggests to add

  use lib '/my/perl5/lib/dir';

When I did that, it all works.  I'm not sure if this is related
to the other failures but it is definitely the problem for
a non-system perl install with INSTALL_BASE and the
use of PERL5LIB.

--Chris


On Wed Apr 30 05:11:58 2014, PLICEASE wrote:
Show quoted text
> I got this (I believe related) error trying to install Inline
> (+Inline::C)
>
> t/08taint.t ............. 1/10 Running Mkbootstrap for
> _08taint_1_p_0965 ()
> chmod 644 _08taint_1_p_0965.bs
> /home/ollisg/perl5/perlbrew/perls/perl-5.18.2c/bin/perl
> /home/ollisg/.perlbrew/libs/perl-5.18.2c@dev/lib/perl5/ExtUtils/xsubpp
> -typemap "/home/ollisg/perl5/perlbrew/perls/perl-
> 5.18.2c/lib/5.18.2/ExtUtils/typemap" _08taint_1_p_0965.xs >
> _08taint_1_p_0965.xsc && mv _08taint_1_p_0965.xsc _08taint_1_p_0965.c
> clang -c -fno-strict-aliasing -pipe -fstack-protector
> -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O2
> -DVERSION=\"0.00\" -DXS_VERSION=\"0.00\" -fPIC "-
> I/home/ollisg/perl5/perlbrew/perls/perl-5.18.2c/lib/5.18.2/x86_64-
> linux/CORE" _08taint_1_p_0965.c
> /bin/sh: 1: clang: not found
> make: *** [_08taint_1_p_0965.o] Error 127
>
> A problem was encountered while attempting to compile and install your
> Inline
> C code. The command that failed was:
> make > out.make 2>&1
>
> The build directory was:
> /home/ollisg/.cpanm/work/1398847813.20092/Inline-
> 0.55/C/_Inline_test/build/_08taint_1_p_0965
>
> To debug the problem, cd to the build directory, and inspect the
> output files.
>
> at ./t/08taint_1.p line 7.
> ...propagated at /home/ollisg/.perlbrew/libs/perl-
> 5.18.2c@dev/lib/perl5/Inline/C.pm line 797.
> BEGIN failed--compilation aborted at ./t/08taint_1.p line 7.
> Compilation failed in require at t/08taint.t line 45.
> # Looks like you planned 10 tests but ran 1.
> # Looks like your test exited with 2 just after 1.
> t/08taint.t ............. Dubious, test returned 2 (wstat 512, 0x200)
> Failed 9/10 subtests
>
> I've installed clang into my home directory because the version that
> comes with my OS is very old. I feel like this configuration should
> be supported, but perhaps not? As a work around I chmod -R -x the
> appropriate directorys in my clang install and the then install
> worked.


  Tue May 06 09:15:50 2014 chm [...] cpan.org - Correspondence added
My use lib line was added just after all the
BEGIN{} blocks in t/08taint.t...

On Tue May 06 09:14:24 2014, CHM wrote:
Show quoted text
> I hit the same error with my cygwin64. In my specific
> case, the issue is that I have all of the added perl
> modules installed into a separate non-system location
> and PERL5LIB is set so that works.
>
> With -T PERL5LIB is not consulted. A look at the pod
> for taint in perlrun suggests to add
>
> use lib '/my/perl5/lib/dir';
>
> When I did that, it all works. I'm not sure if this is related
> to the other failures but it is definitely the problem for
> a non-system perl install with INSTALL_BASE and the
> use of PERL5LIB.
>
> --Chris
  Thu Jun 12 04:34:15 2014 ETJ [...] cpan.org - Correspondence added
RT-Send-CC: alexanderhaeckel [...] lavabit.com, fraserbn [...] gmail.com, inline [...] perl.org
I'd be very interested to know whether the change proposed in https://github.com/mohawk2/inline-pm/commit/f9242a2e92244d99a2ce051c9ae523913eb47fc4 fixes this issue.
  Tue Jun 24 04:17:18 2014 sisyphus [...] cpan.org - Correspondence added
Superseded by #96291 (t/08taint.t fails on perl 5.20.0)
  Tue Jun 24 04:17:19 2014 sisyphus [...] cpan.org - Status changed from 'open' to 'resolved'