Joel Sherrill <joel.sherr...@oarcorp.com> writes: > On 05/18/2012 09:05 AM, Ian Lance Taylor wrote: >> Joel Sherrill<joel.sherr...@oarcorp.com> writes: >> >>> On 05/18/2012 08:27 AM, Ian Lance Taylor wrote: >>>> Ralf Corsepius<ralf.corsep...@rtems.org> writes: >>>> >>>>> I am not sure, but AFAICT, -pthread is Linux-specific. >>>> It's not properly documented, but -pthread works on a number of hosts, >>>> including Solaris, Darwin, FreeBSD, NetBSD, OpenBSD, AIX. >>> Ian.. Is it better to make it a noop for RTEMS or fix the test >>> infrastructure that is turning it on where it doesn't exist? >> Sorry to be vague, but I think it depends on whether the tests are >> meaningful on RTEMS. If dg-require-effective-target pthread_h lets a >> test run, then I suppose I think the -pthread option ought to work. > Ok to be vague. :) > > Is there an implicit assumption that having pthread.h > means a target has libpthread.a and support for the > -pthread option? > > That's a bit of a reach. We have good pthread.h support > but include that in librtemscpu.a which is implicitly linked > against all the time. And obviously no -pthread option. > > if the tests are checking some pthread capability, then > we should be running them. > > I don't mind having -pthread be a noop but the leap > from a having a header file to having a specific gcc > option is a stretch IMO. Unless EVERY gcc target with > pthread support is required by gcc to have that option. > Is that the undocumented(?) intent?
Some systems require the -pthread option to get fully correct behaviour for threaded programs (the -pthread option implies -lpthread, incidentally). I think it would be reasonable for RTEMS to accept the -pthread option. I also think it would be reasonable to fix the testsuite to only use -pthread on systems that require it. Ian
