>> I think you need different check than the usual command completion to
>> determine whether -Kthread should be given or not. If you can
>> suggest some ways to do this with configure macros I will take a stab
>> at it, but I don't understand autoconf/configure well enough. I
>> suspect doing something like
>>
>> c++ -Kthread ... 2>&1 >/dev/null | egrep 'unrecognized option'
>>
>> is too fragile, but that may be the only sort of solution available.
Martin> It's not necessary to understand autoconf at all. Tell me what
Martin> algorithm *you* use to determine that -Kthread is a bad idea,
Martin> and I tell you how to translate it into autoconf.
I used my eyeballs. gcc/g++ as I've now posted a couple times complains
about the -Kthread flag, but goes on to complete the command and exits with
a 0 status. A bit of fiddling I did since my last post suggests it doesn't
like -pthread either, at least not on Mac OS X.
Martin> The current algorithm is not only supposed to find out whether
Martin> -Kthread is available, but also if it has any effect -
Martin> i.e. whether providing that option indeed enables the threads
Martin> library which wouldn't be enabled without it. For some reason,
Martin> it determines that -Kthread is supported and has the desired
Martin> effect.
It has the desired effect presumably because -Kthread isn't required. Gcc
just emits the warning and ignores the flag.
Skip
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4