Hi Sandra,
> On 12/11/2016 01:28 PM, Rainer Orth wrote:
>> Hi Sandra,
>>
>>> PR 16519 notes that -pthread has only ever been documented as an RS6000 and
>>> Solaris 2 option. In fact it's supported by most/all(?) POSIX-flavored
>>> targets, including GNU/Linux, BSD variants, Darwin, etc. It's probably best
>>> to document it as a generic option, with the expectation that GCC supports
>>> -pthread if the underlying operating system or C library provides an
>>> implementation of the POSIX threads API.
>>>
>>> After scratching my head about it, it seemed that it's best categorized as
>>> a linker option even though it also affects the preprocessor on some
>>> targets. I'll wait a day or two before committing the attached patch, in
>>> case anybody wants to argue that this is the wrong way to categorize it.
>>
>> I don't like categorizing it as a linker option: as you say, it affects
>> the preprocessor as well (adding -D_REENTRANT on most systems), and in
>> the past (not completely sure about the present) there were subtle bugs
>> if you forgot to add -pthread during compilation.
>
> Do you have a suggestion for a better place to put it? Preferably *one*
> place, instead of duplicating the docs in 10+ places with target-specific
> options?
I just checked and couldn't find a really good place. It has some
similarity to C Language Options, but doesn't fit since it doesn't
extend the language. Unless you want to introduce a whole new section,
I think the best you can do is list it separately under Preprocessor and
Link Options. I fully agree to not list it individually for each system
that currently supports it. The better route would be to support it for
both compilation and linking on any system that needs either for
symmetry's sake, even if one of the two is just a no-op. Everything
else is just a nightmarish user experience.
Rainer
--
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University
