>> 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