This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [libgomp] Add Unix95 mutex support
I thought configure.tgt was precisely aimed at getting rid of the configure
mess?
It may be a question of style. Personally, I'd hope that configure.tgt
is a *secondary* way of sorting out features, when it's really hard to
devise feature tests. In general, it is easiest to let configure
understand what the right definitions are: if there was a preexisting
AC_SEARCH_LIBS for pthreads, you could have just gone there and add
posix4 -- a smaller and quasi-obvious patch, without the need to check
for the correctness and duplication of the glob patterns. This is
especially true for tests that do not require running a program
(otherwise, you'd still need to look at target triplets to support cross
compilers).
OTOH my build system hacking in GCC has been limited to
configure/makefiles, rather than to C/OS feature tests, so this is
nothing more than an opinion -- I'll defer this to somebody else, I'm
not saying at all that this could block the patch.
So, first this is going to give an uninitialized warning, and second we
could make the code conditional on the existence of
PTHREAD_MUTEX_RECURSIVE, or something like this:
Is PTHREAD_MUTEX_RECURSIVE guaranteed to be a macro?
I don't know. I recall that some identifiers are defined on many
systems *both* as enums (for debugging) and as macros. The only sane
reason why one would do so, is that the standard mandated them to be macros.
Finally, does it harm to define _XOPEN_SOURCE unconditionally for
Solaris 2.5.1/2.6?
I think you cannot reasonably define _XOPEN_SOURCE to 500 for Unix95.
You mean it would give a hard error (#error)?
Paolo