Environment variable $U

Julien ÉLIE julien at trigofacile.com
Tue Feb 9 18:57:19 UTC 2010


Hi Eric,

> Aha.  In many projects, U _is_ initialized, but by automake during
> AM_C_PROTOTYPES, and not by autoconf.  IIUC, the problem can only occur if
> you are using autoconf but not automake.  So one real fix would be to quit
> using U in autoconf, and to teach automake how to override
> _AC_LIBOBJS_NORMALIZE to re-support U; but that has the drawback of
> requiring upgrades in both automake and autoconf simultaneously.

OK, it is true that INN uses autoconf only.


> --- a/lib/autoconf/general.m4
> +++ b/lib/autoconf/general.m4
> @@ -2919,6 +2919,8 @@ AC_DEFUN([AC_LIBOBJ],
>  AC_DEFUN([_AC_LIBOBJS_NORMALIZE],
>  [ac_libobjs=
>  ac_ltlibobjs=
> +m4_ifndef([AM_C_PROTOTYPES], [U=
> +])dnl
>  for ac_i in : $LIB@&t at OBJS; do test "x$ac_i" = x: && continue
>    # 1. Remove the extension, and $U if already installed.
>    ac_script='s/\$U\././;s/\.o$//;s/\.obj$//'
>
> tests/semantics.at:AC_REPLACE_FUNCS also uses $U, so we could see a
> spurious test failure; I'm not sure what to do there.  Thoughts before I
> apply this to autoconf?

I see that you credit me as the reporter.  Could you please credit
Heiko Schlichting instead?  He is the real person who found out the problem.

Thanks again for having investigated on the issue,

-- 
Julien ÉLIE

« Je viens de rencontrer Isocèle : il a une idée pour un nouveau triangle. »
  (Woody Allen) 




More information about the inn-workers mailing list