Skip Menu |

This queue is for tickets about the Math-Pari CPAN distribution.

Report information
The Basics
Id: 120711
Status: open
Priority: 0/
Queue: Math-Pari

People
Owner: Nobody in particular
Requestors: KENTNL [...] cpan.org
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: (no value)



Subject: Fails tests without '.' in @INC

On 5.25.10+ where default_inc_excludes_dot is defined ( default on .11+ ), Math::Pari fails tests with a bunch of blocks that look like unhandled "do $file" failures.

Said failures disappear under PERL_USE_UNSAFE_INC=1

 

PERL_DL_NONLAZY=1 "/home/kent/perl5/perlbrew/perls/5.25.10-nossp-sdbm-nopmc-nodot/bin/perl5.25.10" "-MExtUtils::Command::MM" "-MTest::Harness" "-e" "undef *Test::Harness::Switches; test_harness(0, 'blib/lib', 'blib/arch')" t/
*.t
t/55_analyz.t .............
No subtests run
t/000_load-problem.t ...... ok
t/55_ploth.t ..............
No subtests run
t/55_polyser.t ............
No subtests run
t/55_program.t ............
No subtests run
t/55_sumiter.t ............
No subtests run
t/55_trans.t ..............
No subtests run
t/01_no_extra_newlines.t .. ok
t/55_elliptic.t ...........
No subtests run
t/55_graph.t ..............
No subtests run
t/55_linear.t .............
No subtests run
t/55_nfields.t ............
No subtests run
t/55_number.t .............
No subtests run
t/55_objets.t .............
No subtests run
# Can't locate Term/Gnuplot.pm in @INC, ignoring the test
t/PlotRect.t .............. skipped: Can't locate Term/Gnuplot.pm in @INC
Binary number > 0b11111111111111111111111111111111 non-portable at (eval 3) line 6.
Binary number > 0b11111111111111111111111111111111 non-portable at (eval 3) line 7.
Binary number > 0b11111111111111111111111111111111 non-portable at (eval 3) line 11.
Hexadecimal number > 0xffffffff non-portable at (eval 3) line 12.
Binary number > 0b11111111111111111111111111111111 non-portable at (eval 3) line 13.
t/00_Pari.t ............... ok
t/zz_leak.t ............... ok
Test Summary Report
-------------------
t/55_analyz.t           (Wstat: 0 Tests: 0 Failed: 0)
  Parse errors: No plan found in TAP output
t/55_ploth.t            (Wstat: 0 Tests: 0 Failed: 0)
  Parse errors: No plan found in TAP output
t/55_polyser.t          (Wstat: 0 Tests: 0 Failed: 0)
  Parse errors: No plan found in TAP output
t/55_program.t          (Wstat: 0 Tests: 0 Failed: 0)
  Parse errors: No plan found in TAP output
t/55_sumiter.t          (Wstat: 0 Tests: 0 Failed: 0)
  Parse errors: No plan found in TAP output
t/55_trans.t            (Wstat: 0 Tests: 0 Failed: 0)
  Parse errors: No plan found in TAP output
t/55_elliptic.t         (Wstat: 0 Tests: 0 Failed: 0)
  Parse errors: No plan found in TAP output
t/55_graph.t            (Wstat: 0 Tests: 0 Failed: 0)
  Parse errors: No plan found in TAP output
t/55_linear.t           (Wstat: 0 Tests: 0 Failed: 0)
  Parse errors: No plan found in TAP output
t/55_nfields.t          (Wstat: 0 Tests: 0 Failed: 0)
  Parse errors: No plan found in TAP output
t/55_number.t           (Wstat: 0 Tests: 0 Failed: 0)
  Parse errors: No plan found in TAP output
t/55_objets.t           (Wstat: 0 Tests: 0 Failed: 0)
  Parse errors: No plan found in TAP output
Files=17, Tests=564,  3 wallclock secs ( 0.10 usr  0.03 sys +  3.04 cusr  0.08 csys =  3.25 CPU)

 



-- 
- CPAN kentnl@cpan.org
- Gentoo Perl Maintainer kentnl@gentoo.org ( perl@gentoo.org )
 

CC: perl5-porters [...] perl.org
Subject: Re: [rt.cpan.org #120711] Fails tests without '.' in @INC
Date: Thu, 23 Mar 2017 18:54:13 -0700
To: Kent Fredric via RT <bug-Math-Pari [...] rt.cpan.org>
From: Ilya Zakharevich <nospam-abuse [...] ilyaz.org>
On Thu, Mar 23, 2017 at 08:58:50AM -0400, Kent Fredric via RT wrote: Show quoted text
> Thu Mar 23 08:58:44 2017: Request 120711 was acted upon. > Transaction: Ticket created by KENTNL > Queue: Math-Pari > Subject: Fails tests without '.' in @INC > Broken in: (no value) > Severity: (no value) > Owner: Nobody > Requestors: KENTNL@cpan.org > Status: new > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=120711 > > > > On 5.25.10+ where default_inc_excludes_dot is defined ( default on .11+ ), > Math::Pari fails tests with a bunch of blocks that look like unhandled "do > $file" failures.
This is a bug in Perl. perlfunc is clear about what do EXPR should do: Uses the value of EXPR as a filename and executes the contents of the file as a Perl script. Hope this helps, Ilya

On 2017-03-24 14:54:31, nospam-abuse@ilyaz.org wrote:
> This is a bug in Perl. perlfunc is clear about what
> do EXPR
> should do:
>
> Uses the value of EXPR as a filename and executes the contents of
> the file as a Perl script.
>

Unfortunately for many people, this isn't true.

Read the other lines

----

is largely like

         eval `cat stat.pl`;

except that it's more concise, runs no external processes, keeps
track of the current filename for error messages, searches the
 @INC directories, and updates %INC if the file is found

---

Specifically, "Searches the @INC directories"

https://metacpan.org/pod/distribution/perl/pod/perlfunc.pod#do

I really really wish it was a bug in Perl, but its defined behaviour, and it shares implementation details with "require" ( they're more or less aliases to the same function block but toggle different flags so they have different dealing with exception handling paths )

And it _will_ intentionally behave as I've stated in this bug in the final 5.26 release, P5P know this, and its a "by design" decision at this point.

If things were otherwise, I would have a lot less work triaging this mess :(

-- 
- CPAN kentnl@cpan.org
- Gentoo Perl Maintainer kentnl@gentoo.org ( perl@gentoo.org )
 

CC: Mailing list Perl5 <perl5-porters [...] perl.org>
Subject: Re: [rt.cpan.org #120711] Fails tests without '.' in @INC
Date: Fri, 24 Mar 2017 16:53:48 -0700
To: Kent Fredric via RT <bug-Math-Pari [...] rt.cpan.org>
From: Ilya Zakharevich <nospam-abuse [...] ilyaz.org>
On Thu, Mar 23, 2017 at 10:33:42PM -0400, Kent Fredric via RT wrote: Show quoted text
> > This is a bug in Perl. perlfunc is clear about what > > do EXPR > > should do: > > > > Uses the value of EXPR as a filename and executes the contents of > > the file as a Perl script. > >
Show quoted text
> Read the other lines
Other lines cannot negate what is written in the main line, they may only enhance it. Show quoted text
> is largely like > > eval `cat stat.pl`; > > except that it's more concise, runs no external processes, keeps > track of the current filename for error messages, searches the > @INC directories, and updates %INC if the file is found > > --- > > Specifically, "Searches the @INC directories"
But this does not say that this the ONLY thing it does. Show quoted text
> https://metacpan.org/pod/distribution/perl/pod/perlfunc.pod#do > > I really really wish it was a bug in Perl
It is. Show quoted text
> but its defined behaviour,
The defined behaviour is to look for a FILE, not for a module-like-“thingy”. So if a file is present, it should be loaded. How ELSE can one load a file?! Show quoted text
> and it shares implementation details with "require"
***This*** is a bug. Show quoted text
> And it _will_ intentionally behave as I've stated in this bug in the final 5.26 > release, P5P know this, and its a "by design" decision at this point.
This this decision should be changed — in case of `do´. Unless specifically requested, `do´ should always look for a file — possibly, as a fallback in the case @INC-search failed. Ilya
CC: Kent Fredric via RT <bug-Math-Pari [...] rt.cpan.org>, Mailing list Perl5 <perl5-porters [...] perl.org>
Subject: Re: [rt.cpan.org #120711] Fails tests without '.' in @INC
Date: Sat, 25 Mar 2017 00:10:36 +0000
To: Ilya Zakharevich <nospam-abuse [...] ilyaz.org>
From: Zefram <zefram [...] fysh.org>
Ilya Zakharevich wrote: Show quoted text
>Other lines cannot negate what is written in the main line, they may >only enhance it.
If there is any bug here, it is in the documentation, not the behaviour. -zefram
CC: Kent Fredric via RT <bug-Math-Pari [...] rt.cpan.org>, Mailing list Perl5 <perl5-porters [...] perl.org>
Subject: Re: [rt.cpan.org #120711] Fails tests without '.' in @INC
Date: Sat, 25 Mar 2017 07:46:48 +0100
To: Ilya Zakharevich <nospam-abuse [...] ilyaz.org>
From: demerphq <demerphq [...] gmail.com>
On 25 March 2017 at 00:53, Ilya Zakharevich <nospam-abuse@ilyaz.org> wrote: Show quoted text
> On Thu, Mar 23, 2017 at 10:33:42PM -0400, Kent Fredric via RT wrote:
>> > This is a bug in Perl. perlfunc is clear about what >> > do EXPR >> > should do: >> > >> > Uses the value of EXPR as a filename and executes the contents of >> > the file as a Perl script. >> >
>
>> Read the other lines
> > Other lines cannot negate what is written in the main line, they may > only enhance it. >
>> is largely like >> >> eval `cat stat.pl`; >> >> except that it's more concise, runs no external processes, keeps >> track of the current filename for error messages, searches the >> @INC directories, and updates %INC if the file is found >> >> --- >> >> Specifically, "Searches the @INC directories"
> > But this does not say that this the ONLY thing it does. > >
>> https://metacpan.org/pod/distribution/perl/pod/perlfunc.pod#do >> >> I really really wish it was a bug in Perl
> > It is. >
>> but its defined behaviour,
> > The defined behaviour is to look for a FILE, not for a module-like-“thingy”. So if > a file is present, it should be loaded. How ELSE can one load a file?! >
>> and it shares implementation details with "require"
> > ***This*** is a bug. >
>> And it _will_ intentionally behave as I've stated in this bug in the final 5.26 >> release, P5P know this, and its a "by design" decision at this point.
> > This this decision should be changed — in case of `do´. Unless > specifically requested, `do´ should always look for a file — possibly, > as a fallback in the case @INC-search failed.
You are literally a year or so late to this debate. It has been decided that the security implications of having do read from the current directory by default are unacceptable and that behavior has been removed. It looks like your script is depending on that behavior, and the breakage is part of the fallout of this security precaution. Unfortunately we are not going to revert that, nor concede that the change of behavior is a bug. It is a deliberate, well thought through security decision that your code will have to adapt to. Yves -- perl -Mre=debug -e "/just|another|perl|hacker/"
CC: Kent Fredric via RT <bug-Math-Pari [...] rt.cpan.org>, Mailing list Perl5 <perl5-porters [...] perl.org>
Subject: Re: [rt.cpan.org #120711] Fails tests without '.' in @INC
Date: Mon, 27 Mar 2017 15:53:21 -0600
To: demerphq <demerphq [...] gmail.com>, Ilya Zakharevich <nospam-abuse [...] ilyaz.org>
From: Karl Williamson <public [...] khwilliamson.com>
On 03/25/2017 12:46 AM, demerphq wrote: Show quoted text
> On 25 March 2017 at 00:53, Ilya Zakharevich <nospam-abuse@ilyaz.org> wrote:
>> On Thu, Mar 23, 2017 at 10:33:42PM -0400, Kent Fredric via RT wrote:
>>>> This is a bug in Perl. perlfunc is clear about what >>>> do EXPR >>>> should do: >>>> >>>> Uses the value of EXPR as a filename and executes the contents of >>>> the file as a Perl script. >>>>
>>
>>> Read the other lines
>> >> Other lines cannot negate what is written in the main line, they may >> only enhance it. >>
>>> is largely like >>> >>> eval `cat stat.pl`; >>> >>> except that it's more concise, runs no external processes, keeps >>> track of the current filename for error messages, searches the >>> @INC directories, and updates %INC if the file is found >>> >>> --- >>> >>> Specifically, "Searches the @INC directories"
>> >> But this does not say that this the ONLY thing it does. >> >>
>>> https://metacpan.org/pod/distribution/perl/pod/perlfunc.pod#do >>> >>> I really really wish it was a bug in Perl
>> >> It is. >>
>>> but its defined behaviour,
>> >> The defined behaviour is to look for a FILE, not for a module-like-“thingy”. So if >> a file is present, it should be loaded. How ELSE can one load a file?! >>
>>> and it shares implementation details with "require"
>> >> ***This*** is a bug. >>
>>> And it _will_ intentionally behave as I've stated in this bug in the final 5.26 >>> release, P5P know this, and its a "by design" decision at this point.
>> >> This this decision should be changed — in case of `do´. Unless >> specifically requested, `do´ should always look for a file — possibly, >> as a fallback in the case @INC-search failed.
> > You are literally a year or so late to this debate. > > It has been decided that the security implications of having do read > from the current directory by default are unacceptable and that > behavior has been removed. > > It looks like your script is depending on that behavior, and the > breakage is part of the fallout of this security precaution. > Unfortunately we are not going to revert that, nor concede that the > change of behavior is a bug. It is a deliberate, well thought through > security decision that your code will have to adapt to. > > Yves >
However, we did not do a source audit of the distribution to find affected files that we ship. I noticed this building and testing on win32. Attached is the output of ack --type=perl -H --no-color "\bdo\b\s*(qq?\s*.|'|\")[^.]" > do.log on blead, with some obvious false positives omitted. It includes pods, as we should not be giving bad advice in pods.

Message body is not shown because sender requested not to inline it.

CC: Kent Fredric via RT <bug-Math-Pari [...] rt.cpan.org>, Mailing list Perl5 <perl5-porters [...] perl.org>
Subject: Re: [rt.cpan.org #120711] Fails tests without '.' in @INC
Date: Mon, 27 Mar 2017 20:04:07 -0600
To: demerphq <demerphq [...] gmail.com>, Ilya Zakharevich <nospam-abuse [...] ilyaz.org>
From: Karl Williamson <public [...] khwilliamson.com>
On 03/27/2017 03:53 PM, Karl Williamson wrote: Show quoted text
> On 03/25/2017 12:46 AM, demerphq wrote:
>> On 25 March 2017 at 00:53, Ilya Zakharevich <nospam-abuse@ilyaz.org> >> wrote:
>>> On Thu, Mar 23, 2017 at 10:33:42PM -0400, Kent Fredric via RT wrote:
>>>>> This is a bug in Perl. perlfunc is clear about what >>>>> do EXPR >>>>> should do: >>>>> >>>>> Uses the value of EXPR as a filename and executes the contents of >>>>> the file as a Perl script. >>>>>
>>>
>>>> Read the other lines
>>> >>> Other lines cannot negate what is written in the main line, they may >>> only enhance it. >>>
>>>> is largely like >>>> >>>> eval `cat stat.pl`; >>>> >>>> except that it's more concise, runs no external processes, keeps >>>> track of the current filename for error messages, searches the >>>> @INC directories, and updates %INC if the file is found >>>> >>>> --- >>>> >>>> Specifically, "Searches the @INC directories"
>>> >>> But this does not say that this the ONLY thing it does. >>> >>>
>>>> https://metacpan.org/pod/distribution/perl/pod/perlfunc.pod#do >>>> >>>> I really really wish it was a bug in Perl
>>> >>> It is. >>>
>>>> but its defined behaviour,
>>> >>> The defined behaviour is to look for a FILE, not for a >>> module-like-“thingy”. So if >>> a file is present, it should be loaded. How ELSE can one load a file?! >>>
>>>> and it shares implementation details with "require"
>>> >>> ***This*** is a bug. >>>
>>>> And it _will_ intentionally behave as I've stated in this bug in the >>>> final 5.26 >>>> release, P5P know this, and its a "by design" decision at this point.
>>> >>> This this decision should be changed — in case of `do´. Unless >>> specifically requested, `do´ should always look for a file — possibly, >>> as a fallback in the case @INC-search failed.
>> >> You are literally a year or so late to this debate. >> >> It has been decided that the security implications of having do read >> from the current directory by default are unacceptable and that >> behavior has been removed. >> >> It looks like your script is depending on that behavior, and the >> breakage is part of the fallout of this security precaution. >> Unfortunately we are not going to revert that, nor concede that the >> change of behavior is a bug. It is a deliberate, well thought through >> security decision that your code will have to adapt to. >> >> Yves >>
> > However, we did not do a source audit of the distribution to find > affected files that we ship. I noticed this building and testing on win32. > > Attached is the output of > > ack --type=perl -H --no-color "\bdo\b\s*(qq?\s*.|'|\")[^.]" > do.log > > on blead, with some obvious false positives omitted. It includes pods, > as we should not be giving bad advice in pods.
I created an updated list and any discussion of it should move to [perl #131069]
CC: Ilya Zakharevich <nospam-abuse [...] ilyaz.org>, Kent Fredric via RT <bug-Math-Pari [...] rt.cpan.org>, Mailing list Perl5 <perl5-porters [...] perl.org>
Subject: Re: [rt.cpan.org #120711] Fails tests without '.' in @INC
Date: Tue, 28 Mar 2017 17:36:05 +0200
To: demerphq <demerphq [...] gmail.com>
From: Leon Timmermans <fawaka [...] gmail.com>
On Sat, Mar 25, 2017 at 7:46 AM, demerphq <demerphq@gmail.com> wrote: Show quoted text
> You are literally a year or so late to this debate.
I don't think you're being fair there. He's "a year late" to a debate that is still largely hidden from the world in the security RT queue. and if he's "literally a year or so late" how come this change has landed last weak instead of last June? CPAN authors giving feedback to p5p 4 days after a change landed in an unstable release are not late, they are *early*. Show quoted text
> It is a deliberate, well thought through > security decision that your code will have to adapt to.
If it's well thought through, how come no one on p5p seemed to realize the full impact of this change on do specifically until a month ago? If it's well thought through, how come the documentation around this change is non-existent? If it's well thought through, how come we're still not done updating core tests and modules for this change? Don't get me wrong, I believe this change is unavoidable, but it has become a hasty job that we clearly don't fully have under our control. Even if we are making this change for good reasons, **we are knowingly breaking other people's code without a transition period**, and we should take responsibility for that. I can't think of any appropriate reaction that doesn't contain (and preferably start with) the word "sorry" and has a far more humble tone. TLDR; Ilya, sorry we're breaking your code like this, but we felt we had little choice for reasons that aren't fully in the public domain yet. Leon
CC: Kent Fredric via RT <bug-Math-Pari [...] rt.cpan.org>, Mailing list Perl5 <perl5-porters [...] perl.org>
Subject: Re: [rt.cpan.org #120711] Fails tests without '.' in @INC
Date: Wed, 29 Mar 2017 12:42:39 +0200
To: Leon Timmermans <fawaka [...] gmail.com>, demerphq <demerphq [...] gmail.com>
From: Sawyer X <xsawyerx [...] gmail.com>
[Top-posted] While I agree with most of what you say, Leon, I think you're missing Yves' point - or what I understand to be Yves' point. Unfortunately done in haste, unfortunately with no transition period, but the decision was made and the change is in. With full (and warranted) apologies, it isn't an "Oops! We didn't realize we removed '.' from @INC. Let's bring it back and bikeshed on how to solve it." That's an important distinction and I think that's also what Yves meant. We are apologetic about this, but we are also resolute. On 03/28/2017 05:36 PM, Leon Timmermans wrote: Show quoted text
> On Sat, Mar 25, 2017 at 7:46 AM, demerphq <demerphq@gmail.com> wrote:
>> You are literally a year or so late to this debate.
> I don't think you're being fair there. He's "a year late" to a debate > that is still largely hidden from the world in the security RT queue. > and if he's "literally a year or so late" how come this change has > landed last weak instead of last June? CPAN authors giving feedback to > p5p 4 days after a change landed in an unstable release are not late, > they are *early*. >
>> It is a deliberate, well thought through >> security decision that your code will have to adapt to.
> If it's well thought through, how come no one on p5p seemed to realize > the full impact of this change on do specifically until a month ago? > If it's well thought through, how come the documentation around this > change is non-existent? > If it's well thought through, how come we're still not done updating > core tests and modules for this change? > > Don't get me wrong, I believe this change is unavoidable, but it has > become a hasty job that we clearly don't fully have under our control. > Even if we are making this change for good reasons, **we are knowingly > breaking other people's code without a transition period**, and we > should take responsibility for that. I can't think of any appropriate > reaction that doesn't contain (and preferably start with) the word > "sorry" and has a far more humble tone. > > TLDR; Ilya, sorry we're breaking your code like this, but we felt we > had little choice for reasons that aren't fully in the public domain > yet. > > Leon
CC: Leon Timmermans <fawaka [...] gmail.com>, Kent Fredric via RT <bug-Math-Pari [...] rt.cpan.org>, Mailing list Perl5 <perl5-porters [...] perl.org>
Subject: Re: [rt.cpan.org #120711] Fails tests without '.' in @INC
Date: Wed, 29 Mar 2017 13:21:11 +0200
To: Sawyer X <xsawyerx [...] gmail.com>
From: demerphq <demerphq [...] gmail.com>
On 29 March 2017 at 12:42, Sawyer X <xsawyerx@gmail.com> wrote: Show quoted text
> [Top-posted] > > While I agree with most of what you say, Leon, I think you're missing > Yves' point - or what I understand to be Yves' point. > > Unfortunately done in haste, unfortunately with no transition period, > but the decision was made and the change is in. With full (and > warranted) apologies, it isn't an "Oops! We didn't realize we removed > '.' from @INC. Let's bring it back and bikeshed on how to solve it." > > That's an important distinction and I think that's also what Yves meant. > We are apologetic about this, but we are also resolute.
Yes this, and I didn't mean to be rude. If I was then I apologize. cheers, Yves
CC: demerphq <demerphq [...] gmail.com>, Kent Fredric via RT <bug-Math-Pari [...] rt.cpan.org>, Mailing list Perl5 <perl5-porters [...] perl.org>
Subject: Re: [rt.cpan.org #120711] Fails tests without '.' in @INC
Date: Wed, 29 Mar 2017 14:28:26 -0700
To: Leon Timmermans <fawaka [...] gmail.com>
From: Ilya Zakharevich <nospam-abuse [...] ilyaz.org>
On Tue, Mar 28, 2017 at 05:36:05PM +0200, Leon Timmermans wrote: Show quoted text
> If it's well thought through, how come no one on p5p seemed to realize > the full impact of this change on do specifically until a month ago?
Show quoted text
> TLDR; Ilya, sorry we're breaking your code like this, but we felt we > had little choice for reasons that aren't fully in the public domain > yet.
Because of all the secrecy, all I can do is inference; and from these two chunks of your message, I infer that “these reasons” have nothing to do with `do EXPR´. If so, then the fact that `do EXPR´ and `require´ CURRENTLY use the same code should not be a reason for a complete break up of `do EXPR´. ======================================================= Anyway, the documented behaviour of `do EXPR´ is to load a file. And, so far, nobody yet addressed HOW can one re-implement this documented behaviour when the Perl’s bug in question is present. I cannot add '.' to @INC since this would make the `require´s done from the loaded file unsecure. So: how? Puzzled, Ilya
CC: Leon Timmermans <fawaka [...] gmail.com>, demerphq <demerphq [...] gmail.com>, Kent Fredric via RT <bug-Math-Pari [...] rt.cpan.org>, Mailing list Perl5 <perl5-porters [...] perl.org>
Subject: Re: [rt.cpan.org #120711] Fails tests without '.' in @INC
Date: Wed, 29 Mar 2017 22:49:55 +0100
To: Ilya Zakharevich <nospam-abuse [...] ilyaz.org>
From: Zefram <zefram [...] fysh.org>
Ilya Zakharevich wrote: Show quoted text
>Anyway, the documented behaviour of `do EXPR' is to load a file. And, >so far, nobody yet addressed HOW can one re-implement this documented >behaviour
Stick a "./" on the front of your relative pathname. You need to do this regardless of whether "." is in @INC: to get the behaviour of just loading the file of the supplied name you want to avoid the @INC search entirely. -zefram
CC: Ilya Zakharevich <nospam-abuse [...] ilyaz.org>, Leon Timmermans <fawaka [...] gmail.com>, demerphq <demerphq [...] gmail.com>, Kent Fredric via RT <bug-Math-Pari [...] rt.cpan.org>, Mailing list Perl5 <perl5-porters [...] perl.org>
Subject: Re: [rt.cpan.org #120711] Fails tests without '.' in @INC
Date: Sat, 1 Apr 2017 12:21:40 +0100
To: Zefram <zefram [...] fysh.org>
From: Dave Mitchell <davem [...] iabyn.com>
On Wed, Mar 29, 2017 at 10:49:55PM +0100, Zefram wrote: Show quoted text
> Ilya Zakharevich wrote:
> >Anyway, the documented behaviour of `do EXPR' is to load a file. And, > >so far, nobody yet addressed HOW can one re-implement this documented > >behaviour
> > Stick a "./" on the front of your relative pathname. You need to do this > regardless of whether "." is in @INC: to get the behaviour of just loading > the file of the supplied name you want to avoid the @INC search entirely.
I propose the following change to do's entry in perlfunc, making it clearer if and when @INC is searched: before: =item do EXPR Uses the value of EXPR as a filename and executes the contents of the file as a Perl script. do './stat.pl'; is largely like eval `cat stat.pl`; after: =item do EXPR Uses the value of EXPR as a filename and executes the contents of the file as a Perl script: do './stat.pl'; # file is located relative to the current directory do '/foo/stat.pl'; # file is located at the specified absolute path do 'stat.pl'; # file is searched for within @INC do 'foo/stat.pl'; # file is searched for within @INC do './stat.pl' is largely like eval `cat stat.pl`; -- Indomitable in retreat, invincible in advance, insufferable in victory -- Churchill on Montgomery
CC: Ilya Zakharevich <nospam-abuse [...] ilyaz.org>, Leon Timmermans <fawaka [...] gmail.com>, demerphq <demerphq [...] gmail.com>, Kent Fredric via RT <bug-Math-Pari [...] rt.cpan.org>, Mailing list Perl5 <perl5-porters [...] perl.org>
Subject: Re: [rt.cpan.org #120711] Fails tests without '.' in @INC
Date: Sat, 1 Apr 2017 10:31:06 -0600
To: Dave Mitchell <davem [...] iabyn.com>, Zefram <zefram [...] fysh.org>
From: Karl Williamson <public [...] khwilliamson.com>
On 04/01/2017 05:21 AM, Dave Mitchell wrote: Show quoted text
> On Wed, Mar 29, 2017 at 10:49:55PM +0100, Zefram wrote:
>> Ilya Zakharevich wrote:
>>> Anyway, the documented behaviour of `do EXPR' is to load a file. And, >>> so far, nobody yet addressed HOW can one re-implement this documented >>> behaviour
>> >> Stick a "./" on the front of your relative pathname. You need to do this >> regardless of whether "." is in @INC: to get the behaviour of just loading >> the file of the supplied name you want to avoid the @INC search entirely.
> > > I propose the following change to do's entry in perlfunc, making it > clearer if and when @INC is searched: > > before: > > =item do EXPR > > Uses the value of EXPR as a filename and executes the contents of the > file as a Perl script. > > do './stat.pl'; > > is largely like > > eval `cat stat.pl`; > > after: > > =item do EXPR > > Uses the value of EXPR as a filename and executes the contents of the > file as a Perl script: > > do './stat.pl'; # file is located relative to the current directory > do '/foo/stat.pl'; # file is located at the specified absolute path > > do 'stat.pl'; # file is searched for within @INC > do 'foo/stat.pl'; # file is searched for within @INC > > do './stat.pl' is largely like > > eval `cat stat.pl`; > > >
+1
CC: Ilya Zakharevich <nospam-abuse [...] ilyaz.org>, Leon Timmermans <fawaka [...] gmail.com>, demerphq <demerphq [...] gmail.com>, Kent Fredric via RT <bug-Math-Pari [...] rt.cpan.org>, Mailing list Perl5 <perl5-porters [...] perl.org>
Subject: Re: [rt.cpan.org #120711] Fails tests without '.' in @INC
Date: Sun, 2 Apr 2017 12:45:01 +0200
To: Karl Williamson <public [...] khwilliamson.com>, Dave Mitchell <davem [...] iabyn.com>, Zefram <zefram [...] fysh.org>
From: Sawyer X <xsawyerx [...] gmail.com>
On 04/01/2017 06:31 PM, Karl Williamson wrote: Show quoted text
> On 04/01/2017 05:21 AM, Dave Mitchell wrote:
>> On Wed, Mar 29, 2017 at 10:49:55PM +0100, Zefram wrote:
>>> Ilya Zakharevich wrote:
>>>> Anyway, the documented behaviour of `do EXPR' is to load a file. And, >>>> so far, nobody yet addressed HOW can one re-implement this documented >>>> behaviour
>>> >>> Stick a "./" on the front of your relative pathname. You need to do >>> this >>> regardless of whether "." is in @INC: to get the behaviour of just >>> loading >>> the file of the supplied name you want to avoid the @INC search >>> entirely.
>> >> >> I propose the following change to do's entry in perlfunc, making it >> clearer if and when @INC is searched: >> >> before: >> >> =item do EXPR >> >> Uses the value of EXPR as a filename and executes the contents of >> the >> file as a Perl script. >> >> do './stat.pl'; >> >> is largely like >> >> eval `cat stat.pl`; >> >> after: >> >> =item do EXPR >> >> Uses the value of EXPR as a filename and executes the contents of >> the >> file as a Perl script: >> >> do './stat.pl'; # file is located relative to the current >> directory >> do '/foo/stat.pl'; # file is located at the specified >> absolute path >> >> do 'stat.pl'; # file is searched for within @INC >> do 'foo/stat.pl'; # file is searched for within @INC >> >> do './stat.pl' is largely like >> >> eval `cat stat.pl`; >> >> >>
> > +1
+1 !
CC: Ilya Zakharevich <nospam-abuse [...] ilyaz.org>, Leon Timmermans <fawaka [...] gmail.com>, demerphq <demerphq [...] gmail.com>, Kent Fredric via RT <bug-Math-Pari [...] rt.cpan.org>, Mailing list Perl5 <perl5-porters [...] perl.org>
Subject: Re: [rt.cpan.org #120711] Fails tests without '.' in @INC
Date: Mon, 3 Apr 2017 08:37:15 +0100
To: Zefram <zefram [...] fysh.org>
From: Dave Mitchell <davem [...] iabyn.com>
On Sat, Apr 01, 2017 at 12:21:40PM +0100, Dave Mitchell wrote: Show quoted text
> On Wed, Mar 29, 2017 at 10:49:55PM +0100, Zefram wrote:
> > Ilya Zakharevich wrote:
> > >Anyway, the documented behaviour of `do EXPR' is to load a file. And, > > >so far, nobody yet addressed HOW can one re-implement this documented > > >behaviour
> > > > Stick a "./" on the front of your relative pathname. You need to do this > > regardless of whether "." is in @INC: to get the behaviour of just loading > > the file of the supplied name you want to avoid the @INC search entirely.
> > > I propose the following change to do's entry in perlfunc, making it > clearer if and when @INC is searched:
Now done with v5.25.11-28-g5fc3895 -- Wesley Crusher gets beaten up by his classmates for being a smarmy git, and consequently has a go at making some friends of his own age for a change. -- Things That Never Happen in "Star Trek" #18

The fix for Math-Pari itself looks simple enough, a one-line patch fixes the core problem with "do" assuming "./" and instead explicitly using "./"

The harder part is working around upstream pari ( which this code builds with ) being similarly broken due to its own '.' in @INC shenangans.

However, that too looks like a simple enough fix, just applying it for CPAN users of Math::Pari might be problematic. ( Also attached though )

Though it seems more severe than just failing tests now, and it turns out you might have install failures without these patches.

I haven't thoroughly tested this as much as I'd like, but it does at least pass basic sanity now with PERL_USE_UNSAFE_INC=0 in environment.

As a bonus, I stumbled onto problems compiling Math-Pari when Perl was compiled with -flto, and I fixed that by just lopping -flto out of relevant variables so it works again.  ( Patch also attached ), but I have no idea how good that fix is, and its not necessarily something I'd worry about filing a bug for, so its just presented in case somebody gets bored and finds the addition useful.


-- 
- CPAN kentnl@cpan.org
- Gentoo Perl Maintainer kentnl@gentoo.org ( perl@gentoo.org )
 

Subject: Math-Pari-2.10.809.0-no-dot-inc.patch
From 712cff175abfbf95428ed09a875a15f4047ce105 Mon Sep 17 00:00:00 2001 From: Kent Fredric <kentfredric@gmail.com> Date: Sun, 11 Jun 2017 13:22:46 +1200 Subject: [PATCH] Fix "do" to forcibly use a relative path on Perl 5.26 Reliance on "." in @INC was previously how this worked. But that becomes broken on Perl 5.26 Resolves RT#120711 ( Well, at least the Math-Pari parts, the pari parts themselves need additional fixing, and that's not viable to really perform in Math::Pari ) Bug: https://rt.cpan.org/Ticket/Display.html?id=120711 --- test_eng/ex.t | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/test_eng/ex.t b/test_eng/ex.t index a1a2286..0ad57ee 100644 --- a/test_eng/ex.t +++ b/test_eng/ex.t @@ -10,5 +10,5 @@ $dir1 = "CHANGE_ME"; $dir1 = "$dir/../$dir1" unless $dir1 =~ m|^([a-z]:)?[\\/]|i; @ARGV = "$dir1/src/test/$long_bits/$name"; @ARGV = "$dir1/src/test/32/$name" unless -r $ARGV[0]; -do 'test_eng/Testout.pm'; +do './test_eng/Testout.pm'; die if $@; -- 2.13.1
Subject: no-flto.patch
From c169041dfa888ec3815aa5bacc97bcc0f21dc318 Mon Sep 17 00:00:00 2001 From: Kent Fredric <kentfredric@gmail.com> Date: Sun, 11 Jun 2017 13:05:59 +1200 Subject: [PATCH] Disable -flto as it breaks compile. LTO seems to be bad for static/shared libraries or something. Turning it off until somebody works out how to make it not cause a compile failure, on top of all the crap Pari does. --- Makefile.PL | 17 ++++++++++++----- 1 file changed, 12 insertions(+), 5 deletions(-) diff --git a/Makefile.PL b/Makefile.PL index f3025bd..c32eb6a 100644 --- a/Makefile.PL +++ b/Makefile.PL @@ -42,18 +42,23 @@ Could not find GP/PARI build directory, please run Makefile.PL with paridir=/directory option. EOD +my $optimize = $Config{optimize}; +my $ldflags = $Config{ldflags}; + +s/(^|\s)-flto(\s|$)/$1$2/ for $optimize, $ldflags; + my $gcc_version = defined($Config{gccversion}) ? ", gccversion=$Config{gccversion}" : ""; print <<EOP; Setting up Math::Pari with Perl $] on $^O version $Config{osvers}; cc=$Config{cc}$gcc_version, cccdlflags='$Config{cccdlflags}', ccflags='$Config{ccflags}', - optimize='$Config{optimize}', - ld=$Config{ld}, ldflags='$Config{ldflags}'. + optimize='$optimize', + ld=$Config{ld}, ldflags='$ldflags'. EOP if ($^O eq 'solaris' and $Config{cc} eq 'gcc' - and ( $Config{optimize} =~ s/(?<!\S)(-xarch=386|-xildoff)(?!\S)//g + and ( $optimize =~ s/(?<!\S)(-xarch=386|-xildoff)(?!\S)//g or $Config{cccdlflags} =~ s/(?<!\S)-KPIC(?!\S)/-fPIC/ )) { # Vendor's Perl has major problems with building extensions; try to fix this # One way is to use perlgcc; but it does not work with 5.8.4 @@ -61,7 +66,7 @@ if ($^O eq 'solaris' and $Config{cc} eq 'gcc' print <<EOP; ... Broken config of gcc-on-Solaris detected! I would try to work around this. -... Reset: cccdlflags --> '$Config{cccdlflags}', optimize -> '$Config{optimize}'. +... Reset: cccdlflags --> '$Config{cccdlflags}', optimize -> '$optimize'. EOP } @@ -181,7 +186,7 @@ $define .= ' -DLONG_SHORTER_THAN_IV' if $perl_int_size > $longsize; $define .= ' -Derr=pari_err'; # On linux it can get a wrong dynamic loading $define .= ' -DHAVE_LADD' if $opts{have_ladd}; -$define .= ' -DGCC_INLINE' if $Config{gccversion} and not $Config{optimize} =~ /-g\b/; +$define .= ' -DGCC_INLINE' if $Config{gccversion} and not $optimize =~ /-g\b/; $define .= ' -DHAVE_PARIPRIV' if -f "$paridir/src/headers/paripriv.h"; #$define .= ' -DNO_GRAPHICS_PARI' unless -f "$paridir/src/graph/plotgnuplot.c"; @@ -200,6 +205,8 @@ my $extra_inc = extra_includes($paridir); &WriteMakefile( LIBS => $libs, INC => $extra_inc . ' -I $(PARI_DIR)/src/headers -I $(PARI_DIR)/src -I ./libPARI', + OPTIMIZE => $optimize, + LDFLAGS => $ldflags, NAME => 'Math::Pari', ($common::parilib ? () : (MYEXTLIB => 'libPARI/libPARI$(LIB_EXT)')), -- 2.13.1
Subject: pari-2.3.5-no-dot-inc.patch
From 4f1e00df5ea1e51042146f6277bb1af02f249cc3 Mon Sep 17 00:00:00 2001 From: Kent Fredric <kentfredric@gmail.com> Date: Sun, 11 Jun 2017 10:31:03 +1200 Subject: [PATCH] Fix for 5.26 removal of '.' in @INC Previous scripts assumed CWD was in @INC and that "PARI::822" was in wherever CWD was. This fixes both of those, and the latter, because its not obvious from the build system where one should assume CWD to be. Instead, the absolute path of the directory of these scripts is inserted into @INC --- src/desc/gen_member | 4 ++++ src/desc/gen_proto | 4 ++++ src/desc/merge_822 | 4 ++++ 3 files changed, 12 insertions(+) diff --git a/src/desc/gen_member b/src/desc/gen_member index 2f3cf52..66dea2b 100755 --- a/src/desc/gen_member +++ b/src/desc/gen_member @@ -1,4 +1,8 @@ #!/usr/bin/perl -w +use File::Spec; +use File::Basename qw( dirname ); +use lib dirname(File::Spec->rel2abs(__FILE__)); + use PARI::822; $class='member_functions'; diff --git a/src/desc/gen_proto b/src/desc/gen_proto index 1b507fa..2fb4d3f 100755 --- a/src/desc/gen_proto +++ b/src/desc/gen_proto @@ -1,4 +1,8 @@ #!/usr/bin/perl -w +use File::Spec; +use File::Basename qw( dirname ); +use lib dirname(File::Spec->rel2abs(__FILE__)); + use PARI::822; $class=$ARGV[0]; diff --git a/src/desc/merge_822 b/src/desc/merge_822 index a02d612..9ca8252 100755 --- a/src/desc/merge_822 +++ b/src/desc/merge_822 @@ -1,4 +1,8 @@ #!/usr/bin/perl -w +use File::Spec; +use File::Basename qw( dirname ); +use lib dirname(File::Spec->rel2abs(__FILE__)); + use PARI::822; PARI::822::read(\%funcs,$_,1) -- 2.13.1
CC: ;
Subject: Re: [rt.cpan.org #120711] Fails tests without '.' in @INC
Date: Sun, 29 Jul 2018 01:27:16 -0700
To: Kent Fredric via RT <bug-Math-Pari [...] rt.cpan.org>
From: Ilya Zakharevich <nospam-abuse [...] ilyaz.org>
On Sat, Jun 10, 2017 at 09:37:14PM -0400, Kent Fredric via RT wrote: Show quoted text
> The fix for Math-Pari itself looks simple enough, a one-line patch fixes the > core problem with "do" assuming "./" and instead explicitly using "./"
I know — but I’m sitting on hundreds of scripts written in timespan of decades… Do not think I’m alone in such a situation… Show quoted text
> The harder part is working around upstream pari ( which this code builds with ) > being similarly broken due to its own '.' in @INC shenangans.
I just changed «$^X » to «$^X -I.» in all invocations of these scripts by Math::PariBuilder. Show quoted text
> As a bonus, I stumbled onto problems compiling Math-Pari when Perl was compiled > with -flto, and I fixed that by just lopping -flto out of relevant variables so > it works again. ( Patch also attached ), but I have no idea how good that fix > is, and its not necessarily something I'd worry about filing a bug for, so its > just presented in case somebody gets bored and finds the addition useful.
Interesting… Could you provide more details on your compiler environment (gcc? version?) and how this -flto got there (from Perl’s ./Configure?). Thanks, Ilya
On 2018-07-29 20:27:36, nospam-abuse@ilyaz.org wrote:

Show quoted text
> Interesting… Could you provide more details on your compiler
> environment (gcc? version?) and how this -flto got there (from Perl’s
> ./Configure?).
>

I can probably do a bit better: Here's a travis config that runs on cron that builds an -flto perl.

https://travis-ci.org/gentoo-perl/perl-patchset/jobs/409682234/config
https://github.com/gentoo-perl/perl-patchset/blob/perl-5.24/travis-utils/compile-perl.sh#L23-L31

The gist of doing it is simply setting:

CFLAGS="-O2 -pipe -flto" 
LDFLAGS="-Wl,-O1 -Wl,--as-needed -flto"

Via -Doptimize=${CFLAGS} and -Dldflags=${LDFLAGS} to ./Configure 

Alas, you'll note blead currently is failing its own tests with this flag configuration, despite there being fixes in Configure that previously had problems.

( New tests in EUMM fail hard, and toolchain is a bit of a turd soup with regards to permitting externally-defined compile controls on a per-package basis )

All the same, it would be nice to have them sorted out, because one day we can pray toolchain works here.

( Sorry for brevity, gotta dash )


-- 
- CPAN kentnl@cpan.org
- Gentoo Perl Maintainer kentnl@gentoo.org ( perl@gentoo.org )