http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58996
--- Comment #8 from Paul H. Hargrove <PHHargrove at lbl dot gov> --- (In reply to Barry Tannenbaum from comment #6) > I don't understand the reluctance to check the defintion of > __cpu_set_t_defined, since it's defined right there in > /usr/include/bits/sched.h on my Ubuntu system. Is the problem that it's not > a "top-level" include file? As with must symbols starting with "__", this one is an implementation detail internal to glibc. It may or may not have existed in earlier versions and could be removed or replaced in future versions. The "it's ok because it exists on MY system" defense is entirely inappropriate for a portable software project. Beyond just the issue of using an internal symbol, Jakub rightly points out that there are (at least) three revisions of the affinity API. Use of symbol __cpu_set_t_defined only distinguishes between the no-support case (as on Red Hat 8) and the other three. It does not distinguish AMONG the three other cases. In comment #3 Jakub points out that libgomp already has configure macros for dealing with the affinity stuff. Adopting/adapting those is probably the best approach to the problem.
