This is the mail archive of the
mailing list for the GCC project.
Re: Question on -Werror usage in Makefiles...
> From: Eric Botcazou <firstname.lastname@example.org>
> > The current situation is entirely silly, non-solaris implementations
> > include sol2.h. So e.g. they define "sun" even though they're not
> > from Sun Microsystems. At the same time they prevent us from
> > including legitimate solaris2 headers like sys/mman.h.
> I agree this is a mess.
> > Long term we should fix this by splitting the solaris stuff from the
> > elf? svr4? stuff or whatever it is they have in common, however short
> > term we can fix the warning by prototyping mprotect manually in the
> > sol2.h TRANSFER_FROM_TRAMPOLINE macro.
> Just to fix the warning?
Yes, I'd do the short term fix just to fix the warning. I'd do the
long term suggestion to fix the real problem IMO which is that we
define "sun" on other targets.
Looking through config.gcc, I see that sparc64-openbsd, sparc*-elf,
sparc-rtems, sparclite-elf and sparc86x-*-elf are among the
non-solaris targets which include sol2.h. Unless they redefine
TARGET_OS_CPP_BUILTINS, checking... Some of them do but not all.
Perhaps we could fix the rest and then wrap sys/mman.h in #ifdef sun ?
> This seems like sweeping the problem under the rug
> to me. Which version of the prototype would you choose?
int mprotect(void *addr, size_t len, int prot);
but only if the above idea doesn't work...
> > This requires a fixinclude patch. We already do similar fixinclude
> > hacks in solaris_mutex_init_1 and solaris_mutex_init_2. I'm working
> > on something, but my time is limited so it may take a little while.
> > This is something we should fix regardless of whether the target file
> > -Werror patch is reverted.
> On mainline?
> Eric Botcazou
Sure, if Mark approves it. Otherwise I'd wait till we branch 3.4.
I wouldn't put it on the 3.3 branch yet if that's what you mean. I'd
want to test it on mainline until we were confident it's ok.
Kaveh R. Ghazi email@example.com