bug-gnulib
[Top][All Lists]
Advanced

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

Re: argz.m4: error_t handling wrt argz.h and errno.h


From: Mike Frysinger
Subject: Re: argz.m4: error_t handling wrt argz.h and errno.h
Date: Wed, 13 Feb 2008 14:15:09 -0500
User-agent: KMail/1.9.7

On Wednesday 13 February 2008, Ralf Wildenhues wrote:
> * Mike Frysinger wrote on Wed, Feb 13, 2008 at 07:26:16PM CET:
> > On Wednesday 13 February 2008, Ralf Wildenhues wrote:
> > > * Mike Frysinger wrote on Wed, Feb 13, 2008 at 05:38:05AM CET:
> > > > the argz.m4 header checks to see if error_t is defined, but only does
> > > > so by including the argz.h header.  if you try to build on a system
> > > > that does provide error_t, but not argz.h, the argz replacement
> > > > module fails to build. on glibc systems, error_t is defined in
> > > > errno.h.  perhaps the gl_FUNC_ARGZ should be checking to see if
> > > > errno.h exists and if so, including it.
> > >
> > > I don't quite understand.  If gl_FUNC_ARGZ finds that error_t is not
> > > defined, it defines __error_t_defined in addition to error_t.
> >
> > this must be a semi-recent addition then ... the package i'm looking at
> > does not do that ... here is the snippet from naim:
> > # AC_LTDL_FUNC_ARGZ
>
> The current gnulib module is newer, please try that.  The macro has also
> been renamed to gl_FUNC_ARGZ for gnulib consistency.

i dont maintain naim, i was just trying to build it.  i imagine when upstream 
gets around to updating, they'll do this.

> > > This should keep your errno.h header from defining error_t.
> >
> > shouldnt errno.h also be checked for the error_t type since that is where
> > it actually gets defined ?
>
> Do you know of a system that has error_t that doesn't use
> __error_t_defined?

nope.
-mike

Attachment: signature.asc
Description: This is a digitally signed message part.


reply via email to

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