Chromium requires threads flag
 

Hello,

I have nptl and nptlonly set in my make.conf file.
I thought that was the best setting for threading.


Now, I want to install the Chromium web browser.
It is asking me to the set the +threads flag for ffmpeg,
before www-client/chromium can be installed. OK
no problem on a per package basis.

But, this has made me think. Is setting nptl and
nptl globally (in make.conf) the best idea?

Should the threads flag also be set globally, or just
on a per package basis? Maybe nptl and threads
and not set nptlonly?

I thought nptl and nptl was the end of the
requirements, but running this command:

euse -i threads
Here is a curious response; ffmpeg does not get
listed (as it is not built with the threads flag)?

euse -I threads

I see lots of packages where the flag "threads"
is being used including ffmpeg.


Some discussion and guidance as to how best
to set the flags [nptl, nptlonly and threads]
(any others related to threading) would be
appreciated.


James

Chromium requires threads flag
 

Apparently, though unproven, at 20:56 on Friday 11 February 2011, James did
opine thusly:

> Hello,
>
> I have nptl and nptlonly set in my make.conf file.
> I thought that was the best setting for threading.
>
>
> Now, I want to install the Chromium web browser.
> It is asking me to the set the +threads flag for ffmpeg,
> before www-client/chromium can be installed. OK
> no problem on a per package basis.
>
> But, this has made me think. Is setting nptl and
> nptl globally (in make.conf) the best idea?
>
> Should the threads flag also be set globally, or just
> on a per package basis? Maybe nptl and threads
> and not set nptlonly?
>
> I thought nptl and nptl was the end of the
> requirements, but running this command:
>
> euse -i threads
> Here is a curious response; ffmpeg does not get
> listed (as it is not built with the threads flag)?
>
> euse -I threads
>
> I see lots of packages where the flag "threads"
> is being used including ffmpeg.
>
>
> Some discussion and guidance as to how best
> to set the flags [nptl, nptlonly and threads]
> (any others related to threading) would be
> appreciated.

USE=nptl means build the New Posix Thread Library.
USE=nptlonly means only built NPTL, not the old Linux Threads

These should be global in scope

USE=threads is best per package as some packages support it but don't play
nice with it. You could set it globally and disable it per-package, or do it
the other way round if you please.

AFAIR nptlonly has done nothing for ages. When was LinuxThreads removed from
glibc? Sometime around 2.6 or 2.7?

--
alan dot mckinnon at gmail dot com

Chromium requires threads flag
 

On Fri, Feb 11, 2011 at 1:56 PM, James <wireless@tampabay.rr.com> wrote:
> But, this has made me think. Is setting nptl and
> nptl globally (in make.conf) the best idea?
>
> Should the threads flag also be set globally, or just
> on a per package basis? Maybe nptl and threads
> and not set nptlonly?
>

I have threads set globally in make.conf and haven't run into any
issues. nptl and nptlonly are set via make.defaults in amd64 profile.

It doesn't seem like too many of the packages I actually use have a
"threads" use flag:

floppym@naomi ~ % equery hasuse threads | cat
app-arch/xz-utils-5.0.1
app-emulation/wine-1.3.13
dev-cpp/clucene-0.9.21b-r1
dev-cpp/libthrowable-1.1.0
dev-lang/python-2.6.6-r1
dev-lang/python-2.7.1
dev-lang/python-3.1.2-r4
dev-lang/ruby-1.8.7_p302
dev-lang/tcl-8.5.8-r1
dev-lang/tk-8.5.8-r1
dev-libs/beecrypt-4.1.2-r1
dev-vcs/git-1.7.3.4-r1
media-libs/libvpx-0.9.5
media-libs/x264-0.0.20101029
media-video/ffmpeg-0.6_p25767
net-analyzer/wireshark-1.4.3
net-dns/bind-9.7.2_p3-r3
net-print/cups-1.4.6

I'm sure many other packages use threads, but it isn't optional.

Chromium requires threads flag
 

Alan McKinnon <alan.mckinnon <at> gmail.com> writes:


> These should be global in scope, <nptl and nptlonly>

> USE=threads is best per package as some packages support it but don't play
> nice with it.


Yep this is the advise I'm using....

Chromium's call for ffmpeg to use the *threads* flag,
caught me as a little off. Oh well it seems to be
compiling just fine...


thx,
James