bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Detection of utmp/pty for *BSD.


From: Mats Erik Andersson
Subject: Re: Detection of utmp/pty for *BSD.
Date: Fri, 10 Sep 2010 00:19:08 +0200
User-agent: Mutt/1.5.18 (2008-05-17)

torsdag den  9 september 2010 klockan 21:39 skrev Bruno Haible detta:
> Hello Mats,
> 
> Thank you for your reports. Can you please also say on which
> versions of OpenBSD and FreeBSD you observed the problems?
> I need this info for investigating and for documenting the issue.
> 
> Bruno

The quick punch lines first:

   * <utmp.h>  is __NOT__ self-contained, neither for OpenBSD, nor FreeBSD.

   * <libutil.h>  is __NOT__ self-contained for FreeBSD.

In contrast,

   * <util.h>  __is__ self-contained for OpenBSD.


The following code fails to compile for OpenBSD 4.4 and 4.6, as well
as for FreeBSD 6.4 and 8.0:

   #include <utmp.h>

   int main(void) {
       return 0;
   }

The next code fails for FreeBSD 6.4 and 8.0:

   #include <libutil.h>

   int main(void) {
       return 0;
   }

All these failures are rescued by the simple insertion of a single

   #include <sys/types.h>

before either of the original header files, but not after!

I have verified the above failures with the given snippets,
but they were originally discovered after bootstrapping the
code for GNU Inetutils from the git-HEAD stage.

Like there is a test whether <sys/socket.h> is self-contained
in any given OS, my observations suggest that similar tests
for self-containedness of <utmp.h> and <libutil.h> would
indeed improve the relevance of the autoconfiguration.

As the typical examples of this necessity let me mention that
some tests performed for openpty() on FreeBSD, and for getutent()
on OpenBSD and FreeBSD, fail a priory because the corresponding
header file are non-self-contained. That getutent() in reallity
is non-existent in OpenBSD and FreeBSD is in fact a conclusion
that can not be drawn from the tests, as they are recorded by
the logging into "config.log".


Regards,
Mats Erik Andersson, fil. dr



reply via email to

[Prev in Thread] Current Thread [Next in Thread]