This is the mail archive of the
mailing list for the binutils project.
Re: [RFA] bfd/elf.c: remove #define _SYSCALL32
- From: Joern Rennecke <joern dot rennecke at st dot com>
- To: msnyder at redhat dot com
- Cc: bug-binutils at gnu dot org, binutils at sources dot redhat dot com
- Date: Tue, 16 Apr 2002 09:32:50 +0100
- Subject: Re: [RFA] bfd/elf.c: remove #define _SYSCALL32
- Organization: SuperH UK Ltd.
- References: <3CB413EC.E7BD661F@st.com> <3CB5CDA2.484C480A@redhat.com> <3CBAC2F4.B57AF898@st.com> <3CBB17FE.C0BCAEAC@redhat.com>
- Reply-to: joern dot rennecke at st dot com
> Joern Rennecke wrote:
> > P.S.: I've just tried a native solaris 2.8 build with this
> > patch, and it failed. When compiling elf.c, it is missing
> > the types prstatus32_t and elfcore_psinfo32_t .
> > The problem is that autoconf made its decisions with a test
> > defining _SYSCALL32, and then elf.c got compiled without that
> > define. Now, for the native build, if I add -D_SYSCALL32 to
> > the gcc invocation, it succeeds.
> > Should we use a different test for _SYSCALL32 when doing a
> > native build?
> > Or should we guard the uses of _SYSCALL32 specific types
> > by tests of HAVE__SYSCALL32 as well as tets of the type-specific
> > macros?
> > Or should we decide early on if we are going to use _SYSCALL32,
> > and then define / not define it accordingly in the sys/procfs.h
> > type tests?
> It needs to be defined if and only if your target is
> 64-bit Sparc Solaris. Although actually, I'm not sure
> why the define was giving you trouble in the first place.
I was building with gcc 220.127.116.11 . Yesterday I built the cross
sucessfully using gcc 2.95.2 Should we consider building with
gcc 18.104.22.168 as unsupported for this host/target combination, or
should I look closer at the reason why things went wrong?
2430 Aztec West / Almondsbury / BRISTOL / BS32 4AQ
T:+44 1454 462330