Re: argz.m4: error_t handling wrt argz.h and errno.h
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 signature.asc Description: This is a digitally signed message part. ___ Bug-libtool mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: argz.m4: error_t handling wrt argz.h and errno.h
* 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. > > 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? Cheers, Ralf ___ Bug-libtool mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: argz.m4: error_t handling wrt argz.h and errno.h
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 # - AC_DEFUN([AC_LTDL_FUNC_ARGZ], [AC_CHECK_HEADERS([argz.h]) AC_CHECK_TYPES([error_t], [], [AC_DEFINE([error_t], [int], [Define to a type to use for `error_t' if it is not otherwise available.])], [#if HAVE_ARGZ_H # include #endif]) since it wasnt defining __error_t_defined, errno.h fell apart due to the error_t duplication. > 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 ? -mike signature.asc Description: This is a digitally signed message part. ___ Bug-libtool mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: argz.m4: error_t handling wrt argz.h and errno.h
[ Cc:ing bug-libtool, it's upstream for argz ] Hi Mike, * 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 should keep your errno.h header from defining error_t. Can you please show the relevant config.log snippets, to find out where this goes wrong? There are more headers that might define error_t, argp.h for example. Thanks, Ralf ___ Bug-libtool mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-libtool
