Re: FW: dpkg support for Solaris
On Tue, 2011-11-15 at 15:22:46 +0100, Raphael Hertzog wrote:
> On Mon, 14 Nov 2011, Andrew Stormont wrote:
> > diff --git a/lib/dpkg/md5.c b/lib/dpkg/md5.c
> > index 3da18c9..5e9f311 100644
> > --- a/lib/dpkg/md5.c
> > +++ b/lib/dpkg/md5.c
> > @@ -15,6 +15,8 @@
> > * MD5Context structure, pass it to MD5Init, call MD5Update as
> > * needed on buffers full of bytes, and then call MD5Final, which
> > * will fill a supplied 16-byte array with the digest.
> > + *
> > + * Copyright © 2011 Nexenta Systems Inc. All rights reserved.
> > */
> That file is in the public domain and it's best if we keep it that way, so
> please accept the same and don't claim any copyright on it.
This does not matter any more given the pushed changes, but in
addition I don't think these changes are copyrightable, as they are
just a symbol rename (at least according to the GNU maintainers doc).
> Hum, C99 is not a requirement to build dpkg. Some features are required
> but those standard types are currently not part of it (see README and
> doc/coding-style.txt). So maybe it's better to add the required typedefs
> specifically for Solaris?
They are assumed to be present, and checked by dpkg-compiler.m4. Those
are not on the doc, because they don't really need compiler support,
and can be easily mapped to other types by configure.
> That said I don't really know why Guillem did not mandate C99 in its
Because C99 is not yet fully implemented by many compilers (not even gcc).
> > +#ifdef HAVE_SYS_CDEFS
> > #include <sys/cdefs.h>
> > +#endif
> So this test should probably be changed into something else. Not sure
> what though... this header is provided by glibc but is not glibc specific
> If we can't find anything better, we could go with this I guess:
> #if !defined(__sun)
> #include <sys/cdefs.h>
It's a BSDism and it's not needed.
> > @@ -31,6 +33,7 @@
> > # define OSHurd
> > #elif defined(__sun)
> > # define OSsunos
> > +# undef HAVE_KVM_H
> > #elif defined(OPENBSD) || defined(__OpenBSD__)
> > # define OSOpenBSD
> > #elif defined(hpux)
> Why? Does kvm.h exist on Solaris and is it something totally unrelated?
kvm implementations vary slightly from system to system, given that
they expose kernel internal structures to user-land.