This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Patch to get ia64-aix cross-compiling cc1
- To: zack at codesourcery dot com
- Subject: Re: Patch to get ia64-aix cross-compiling cc1
- From: "Kaveh R. Ghazi" <ghazi at caip dot rutgers dot edu>
- Date: Tue, 13 Nov 2001 12:13:15 -0500 (EST)
- Cc: gcc-patches at gcc dot gnu dot org, wilson at redhat dot com
> From: Zack Weinberg <zack@codesourcery.com>
>
> On Tue, Nov 13, 2001 at 11:03:42AM -0500, Kaveh R. Ghazi wrote:
> > When cross-compiling from sparc-sun-solaris2.7 to ia64-unknown-aix, I
> > get the following error:
> >
> > > In file included from hconfig.h:9,
> > > from gengenrtl.c:22:
> > > config/ia64/aix.h:256:25: sys/machine.h: No such file or directory
> > > make: *** [gengenrtl.o] Error 1
> >
> > There is a hack in ia64/aix.h to handle the fact that on ia64-aix the
> > sys/machine.h header defines REG_SIZE which conflicts with gcc's copy
> > of that macro. The problem is that this fix is only relevant on that
> > platform where sys/machine.h exists, not in the cross-compile case
> > when host/build != ia64-aix.
> >
> > I think the right fix is to create an xm- file and move that hack
> > there. Tested by cross-compiling cc1, however I would like some
> > confirmation that this is the right approach in the native case as
> > well.
>
> This is papering over the problem. Why is sys/machine.h being
> included in the first place? I find no references to it outside of
> config/ia64/aix.h. Presumably it is being dragged in by some other
> header.
Probably.
>
> In any case, introducing xm-headers is a step in the wrong direction.
I understand your stance against new xm-headers given the work you did
eliminating the unnecessary ones. That doesn't necessarily mean we
should never use them. If there's a situation which merits it, we
should be free to proceed (perhaps with caution.)
> The appropriate fix in my book is to figure out which header is
> bringing in sys/machine.h. If we don't need that header, we should
> stop including it. If we do, we should put an unconditional #undef
> REG_SIZE immediately after it, with a comment explaining that AIX
> defines that macro.
> zw
IMHO, this would be a very fragile/brittle solution. We can't
guarantee that this supposedly one place will forever be the only way
that file gets sucked in.
Secondly, I don't have one of these systems to do an audit of how
sys/machine.h gets pulled in, I can only cross-compile to it and fix
it that way.
--Kaveh
--
Kaveh R. Ghazi Engagement Manager / Project Services
ghazi@caip.rutgers.edu Qwest Internet Solutions