Re: RFA: Solaris 10 fixincludes tweak

["Bruce Korb" <bruce dot korb at gmail dot com>]

On 8/27/07, Mark Mitchell <mark@codesourcery.com> wrote:
>
> I recently tried to use a compiler built for SPARC Solaris 8 on a
> Solaris 10 systems.  I reran the fixincludes installed with the
> compiler -- but ended up with a broken <pthread.h>.
....
> The root cause is that fixincludes has fixes that it wants to apply
> only to Solaris <10, and uses a "mach" test to check that.  However,
> the installed "mkheaders" program hard-codes the target triplet, so
> the machine fixincludes sees is always going to be
> sparc-sun-solaris2.8, even if run on Solaris 10.
......
Maybe the real best fix is to send a patch to *Sun* suggesting that
they fix their initializer code so that there is a #define initializer for
upad64_t that varies by whether it is a fundamental type or a union.
Until that is done, there will always be some sort of grief.  So for now,
we have to kludge our way along.

> The more proximate cuase is that the condition for whether or not
> upad64_t is a union or an integer type is:
>
>   #if __STDC__ - 0 == 0 && !defined(_NO_LONGLONG)
>
> on older Solaris, and:
>
>   #if (_HAVE_LONGLONG)
>
> on newer Solaris.  The Solaris headers arrange that the latter is
> always true for GCC, but the former, with -ansi, is false.  So, I
> changed the fix to check to see that the __STDC__ formulation appears
> in sys/types.h.
>
> Is this patch OK?  Any better ideas?

The perfect solution would be to write a C-code fix that parsed the sys/types.h
header to emit a pthread.h wrapper to #undef the broken defines and emitted
alternate text initializers using the same #if conditions found in sys/types.h
for the upad64_t thingey. a la:

#ifndef GUARD
#define GUARD 1
#include_next <pthread.h>

#if whatever
#define UPAD64_INITIALIZER whatevervariation
#else
#define UPAD64_INITIALIZER notwhatevervariation
#endif

#undef PTHREAD_MUTEX_INITIALIZER
#define PTHREAD_MUTEX_INITIALIZER { ... UPAD64_INITIALIZER ...}
// et al.
#endif /* GUARD */

i.e. the way Sun should have done it from the get-go.
I can quickly put together the infrastructure if someone wants to fill
in the parsing and emitting code.  I'm about to go on vacation and have
a few projects to get done, so I would not get to it until October or
even November.  Hopefully, that would fix the perennial issue once and
for all.

Good luck.  :)  Cheers - Bruce

P.S. another approach would be to modify GCC so that ``{}'' was an
always-valid initializer that would remove the need to exactly match
the underlying structure.  (As long as all elements were zero, of course.)