Disable lang/perl5 threads by default

[Jonathan Perkin]

For the last couple of releases, Perl has officially discouraged the
use of ithreads:

https://metacpan.org/changes/distribution/perl#Interpreter-based-threads-are-now-discouraged

Our options.mk enables threads by default if they are builtin, which
is probably the vast majority of platforms by now.

I propose we remove the PKG_SUGGESTED_OPTIONS setting, and leave it to
the user to enable them if required, so that we match the upstream
recommendation.

Objections?

[Greg Troxel]

Post by Jonathan Perkin
For the last couple of releases, Perl has officially discouraged the
https://metacpan.org/changes/distribution/perl#Interpreter-based-threads-are-now-discouraged
Our options.mk enables threads by default if they are builtin, which
is probably the vast majority of platforms by now.
I propose we remove the PKG_SUGGESTED_OPTIONS setting, and leave it to
the user to enable them if required, so that we match the upstream
recommendation.

Do you know what will break/change if this is done?

Absent a good argument, I think following upstream's recommendations is
in order.

[Jens Rehsack]

Post by Greg Troxel

Post by Jonathan Perkin
For the last couple of releases, Perl has officially discouraged the
https://metacpan.org/changes/distribution/perl#Interpreter-based-threads-are-now-discouraged
Our options.mk enables threads by default if they are builtin, which
is probably the vast majority of platforms by now.
I propose we remove the PKG_SUGGESTED_OPTIONS setting, and leave it to
the user to enable them if required, so that we match the upstream
recommendation.

Do you know what will break/change if this is done?

DBD::Oracle usage for our perl will break. A lot of commercial software relying
on threads break (darkpan). Rjbs (current pumpkin) is currently on a road where
he's ignoring darkpan. I'm not sure whether I will follow this road.

Post by Greg Troxel
Absent a good argument, I think following upstream's recommendations is
in order.

Generally yes, but in that case no. And it's not a depreciation - it's discouraged.

For the records: It's not recommended by perl people to "use threads" - but
only for 2 reasons:
1) using threads slows down the interpreter by 20%
2) using threads is ineffective because it uses a fork-simulation controlled by perl itself.

It is recommended because it's ineffective - not because it's broken. We (pkgsrc)
might try to follow the road of depending on packages + features - then I would
recommend turning of p5 threads by default. We can easily mark all packages requiring
threads using the feature notation then.

Further: I recommend to run "make test" in bulk-builds then to get quick feedback
about consequences when such changes are made (looks as if I actually collecting tuit's).

@Riba: Sounds as another C::AC check needed for D::O - have_threads :)

Cheers

[Hauke Fath]

Post by Greg Troxel
Do you know what will break/change if this is done?
Absent a good argument, I think following upstream's recommendations is
in order.

See also PR pkg/46280.

hauke

[Jens Rehsack]

Post by Hauke Fath

Post by Greg Troxel
Do you know what will break/change if this is done?
Absent a good argument, I think following upstream's recommendations is
in order.

See also PR pkg/46280.

I don't see any reason for this PR. Seems to me a dirty workaround for broken
OS condition. I have no problems on NetBSD 6.1 with perl and threads.

Cheers

[Hauke Fath]

Post by Jens Rehsack

Post by Hauke Fath
See also PR pkg/46280.

I don't see any reason for this PR. Seems to me a dirty workaround
for broken OS condition. I have no problems on NetBSD 6.1 with perl and

threads.

I see. Then the issue must not exist. I shall close the PR straight
away.

hauke

(any sarcasm you found is yours to keep)

[Jens Rehsack]

Post by Jens Rehsack

Post by Jens Rehsack

Post by Hauke Fath
See also PR pkg/46280.

I don't see any reason for this PR. Seems to me a dirty workaround
for broken OS condition. I have no problems on NetBSD 6.1 with perl and

threads.
I see. Then the issue must not exist. I shall close the PR straight
away.
hauke
(any sarcasm you found is yours to keep)

There is seriously an issue, but it's not necessarily related to perl or
p5-Digest-SHA. It's probably an issue somewhere else.

Can you repeat it on any other non-beta NetBSD version? If not, I suggest
address it in NetBSD, not in pkgsrc. Is it i386 only or are other architectures
affected, too? Was the perl compiled straight for named OS version or were
there some src/ updates in meantime?

I also wonder where the -L/usr/local/lib is coming from and what's installed
there. The --whole-archive scares me, too.

So basically, the ticket looks weird to me and while I like being
surprised - I don't expect this report leads to any perl related issue.

Cheers

[Hauke Fath]

On Thu, 12 Jun 2014 18:39:45 +0200, Jens Rehsack wrote:

[PR pkg/46280]

Post by Jens Rehsack
There is seriously an issue, but it's not necessarily related to perl or
p5-Digest-SHA. It's probably an issue somewhere else.
Can you repeat it on any other non-beta NetBSD version? If not, I suggest
address it in NetBSD, not in pkgsrc.

Certainly possible.

Post by Jens Rehsack
Is it i386 only or are other architectures
affected, too? Was the perl compiled straight for named OS version or were
there some src/ updates in meantime?

Well, it's been a year...

It happened, as the PR says, off and on during a year. When
p5-Digest-SHA
dumped core, neither rebuilding perl nor a system update would make a
difference.

ISTR I saw the problem on more than one machine, but I am not 100% sure.

Since the hacks.mk addition, I haven't seen the problem again, ever,
across several perl and system updates. Good enough evidence for me...
I remember a similar issue with bind9 on sparc, which liked to
spin-loop with 100% cpu until I built it without thread support.

Post by Jens Rehsack
I also wonder where the -L/usr/local/lib is coming from and what's installed
there. The --whole-archive scares me, too.

For lack of perl fu, I cannot comment.

hauke

[Jens Rehsack]

Post by Hauke Fath
[PR pkg/46280]

Post by Jens Rehsack
There is seriously an issue, but it's not necessarily related to perl or
p5-Digest-SHA. It's probably an issue somewhere else.
Can you repeat it on any other non-beta NetBSD version? If not, I suggest
address it in NetBSD, not in pkgsrc.

Certainly possible.

Post by Jens Rehsack
Is it i386 only or are other architectures
affected, too? Was the perl compiled straight for named OS version or were
there some src/ updates in meantime?

Well, it's been a year...
It happened, as the PR says, off and on during a year. When
p5-Digest-SHA
dumped core, neither rebuilding perl nor a system update would make a
difference.
ISTR I saw the problem on more than one machine, but I am not 100% sure.
Since the hacks.mk addition, I haven't seen the problem again, ever,
across several perl and system updates. Good enough evidence for me...
I remember a similar issue with bind9 on sparc, which liked to
spin-loop with 100% cpu until I built it without thread support.

But you don't know the reason and just fixed the symptom. Fair enough
from operation point of view - but not enough for reasonable fix.

I'm pretty sure it has nothing to do with perl but with some other
things going on there ...

Post by Hauke Fath

Post by Jens Rehsack
I also wonder where the -L/usr/local/lib is coming from and what's installed
there. The --whole-archive scares me, too.

For lack of perl fu, I cannot comment.

Well - that's not perl fu (foo?) - it's about setting CFLAGS and LDFLAGS. I
proved over my pkgsrc and perlbrew installations - I see that nowhere. The
weird path's and --whole-archive (http://stackoverflow.com/questions/805555/ld-linker-question-the-whole-archive-option)
makes me believe that the system is grown and likely not sane. Tiny quirks
might lurk in the deep and you recognize(d) symptoms of relics.

Cheers

[David Holland]

Post by Hauke Fath
I remember a similar issue with bind9 on sparc, which liked to
spin-loop with 100% cpu until I built it without thread support.

That has recently been traced to a pthread bug in base.

[Richard PALO]

Post by Jonathan Perkin
For the last couple of releases, Perl has officially discouraged
https://metacpan.org/changes/distribution/perl#Interpreter-based-threads-are-now-discouraged
Our options.mk enables threads by default if they are builtin,
which is probably the vast majority of platforms by now.
I propose we remove the PKG_SUGGESTED_OPTIONS setting, and leave it
to the user to enable them if required, so that we match the
upstream recommendation.
Objections?

Jonathan, for my part I've set 'PKG_OPTIONS.perl= -threads' in my
mk.conf since your post and so far the only apparent issue for the
packages I use so far seems to be a 'known' install-time issue with

Post by Jonathan Perkin
=> Becoming ``root'' to make su-real-package-install (pfexec) ===>
Install binary package of p5-subversion-1.8.10 ==>
p5-subversion-1.8.10 requires a Perl that supports threads.
pkg_add: install script returned error status pkg_add: 1 package
addition failed *** Error code 1