[Mono-devel-list] Non GCC compiler patch - ip_mreq & HP'sheaders
Bernie Solomon
bernard at ugsolutions.com
Thu May 22 12:17:54 EDT 2003
io-layer/daemon-messages.c needs _XOPEN_SOURCE_EXTENDED for cmsghdr so it
seems impossible to have this compile and socket-io.c at the same time - but
this is the only file that needs it. So an alternative which feels slightly
less yucky is to have _XOPEN_SOURCE defined everywhere by configure
#ifdef __hpux // is this the right symbol? or should it be something defined
by configure.
#define _XOPEN_SOURCE_EXTENDED
#endif
at the top of daemon-messages.c to get cmsghdr.
BTW - I have seen no answers to my question on the type to use for an int
big enough to hold a pointer - is there an official story on that?
Bernie Solomon
----- Original Message -----
From: "Dick Porter" <dick at ximian.com>
To: "Bernie Solomon" <bernard at ugsolutions.com>
Cc: <mono-devel-list at lists.ximian.com>
Sent: Thursday, May 22, 2003 8:39 AM
Subject: Re: [Mono-devel-list] Non GCC compiler patch - ip_mreq &
HP'sheaders
> On Wed, 2003-05-21 at 22:46, Bernie Solomon wrote:
> > I looked at this a little more. So far the best I have come up with is
have
> > _XOPEN_SOURCE_EXTENDED defined for all compiles as it is needed in other
> > files and in socket-io.c have something like:
> >
> > #ifdef __hpux // or some equivalent
> > #undef _XOPEN_SOURCE_EXTENDED
> > #define _XOPEN_SOURCE
> > #endif
> >
> > before the appropriate includes so that ip_mreq comes out (it is under
an
> > ifndef _XOPEN_SOURCE_EXTENDED in /usr/include/netinet/in.h). Ugly but at
> > least the code is compiled in this way.
>
> Yuck.
>
> Do you know offhand which other places require the _EXTENDED define? Is
> it possible to have configure.in give a set of preprocessor flags that
> do the right thing for hpux everywhere? If not then we'll just have to
> live with that workaround in socket-io.c.
>
> Apart from this struct ip_mreq business, the changes to io-layer,
> monitor.c and process.c look fine to me. The other changes will have to
> be reviewed by the owners of those bits of code.
>
> - Dick
>
>
More information about the Mono-devel-list
mailing list