[Libvir] [PATCH] header file changes for Solaris
Daniel P. Berrange
berrange at redhat.com
Fri Jun 15 13:08:59 UTC 2007
On Fri, Jun 15, 2007 at 09:03:42AM -0400, Daniel Veillard wrote:
> On Fri, Jun 15, 2007 at 01:59:41PM +0100, Daniel P. Berrange wrote:
> > On Fri, Jun 15, 2007 at 09:06:55AM +0100, Richard W.M. Jones wrote:
> > > Daniel P. Berrange wrote:
> > > >On Thu, Jun 14, 2007 at 05:26:39PM -0400, Mark Johnson wrote:
> > > >>This patch has the includes need to build on Solaris.
> > > >>I've been using ifdef linux & ifndef linux to distinguish
> > > >>between solaris and linux at this point.
> > > >
> > > >Looks ok aside from
> > > [..]
> > >
> > > No, I don't agree. We should use configure.in to test for the presence
> > > of header files and then do things like:
> > >
> > > #ifdef HAVE_STRINGS_H
> > > #include <strings.h>
> > > #endif
> >
> > For strings.h I don't see the point in making it conditional really, unless
> > we're going to do the same for every single other header we include. The
> > strings.h header is always present on Linux. In recent times stuff that was
> > previously in strings.h has moved to string.h, but they're still in the
> > original header too. So we should always include both string.h & strings.h
> > for maximum portability.
>
> Hum, I don't think they are really the same. In libxml2 I do a configure
> test for HAVE_STRINGS_H but string.h is included without checks in a lot of
> places.
They're not the same - I string.h is a superset of strings.h on Linux, but
on other places they're disjoint sets.
Comment in strings.h...
/* We don't need and should not read this file if <string.h> was already
read. The one exception being that if __USE_BSD isn't defined, then
these aren't defined in string.h, so we need to define them here. */
Dan.
--
|=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=|
|=- Perl modules: http://search.cpan.org/~danberr/ -=|
|=- Projects: http://freshmeat.net/~danielpb/ -=|
|=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
More information about the libvir-list
mailing list