Re: autoconf-2.50 issues...

[Guillaume Cottenceau]

Akim Demaille <address@hidden> writes:


> Please, write to public lists, not to me.

Sorry..

 
> | I'm experiencing several different problems recompiling many programs with
> | autoconf-2.50.
> | 
> | Do you have some documentation describing what changed from the user point
> | of view, between 2.13 and 2.50, a sort of "what to do when upgrading"?
> 
> ISTR that there is one, indeed, but maybe it's not enough.

Where can I find it?

I can't find it from the sources, at least. For example 

address@hidden ~/rpm/BUILD/autoconf-2.50] find -type f | xargs grep 
AC_TRY_RUN_NATIVE
./ChangeLog:    (AC_TRY_RUN_NATIVE): Remove.
./ChangeLog:    (AC_TRY_RUN): Use AC_RUN_IFELSE, not AC_TRY_RUN_NATIVE.
./ChangeLog:    (AC_TRY_COMPILER, AC_EGREP_CPP, AC_TRY_RUN_NATIVE): Use
./ChangeLog:    AC_TRY_LINK, AC_TRY_RUN_NATIVE): Simplify the removal of the
./ChangeLog:    AC_EGREP_CPP, AC_TRY_LINK, AC_COMPILE_CHECK, AC_TRY_RUN_NATIVE):
./ChangeLog:    AC_TRY_COMPILE, AC_TRY_LINK, AC_TRY_RUN_NATIVE, AC_CHECK_FUNC):
./ChangeLog:    AC_TRY_RUN_NATIVE, AC_OUTPUT_CONFIG_STATUS): Use @PND@ instead 
of
./ChangeLog:    (AC_TRY_COMPILER, AC_TRY_LINK, AC_TRY_RUN_NATIVE): Likewise.
./ChangeLog:    * acgeneral.m4 (AC_TRY_RUN_NATIVE): Fail if linking fails, like
./ChangeLog:    * acgeneral.m4 (AC_TRY_RUN_NATIVE, AC_TRY_LINK, AC_TRY_COMPILE,
./ChangeLog:    * acgeneral.m4 (AC_TRY_RUN_NATIVE): Split out of AC_TRY_RUN.
./aclang.m4:# directives must not be included.  But AC_TRY_RUN_NATIVE was not

 
> | Also, the on-line manual (http://sources.redhat.com/autoconf/) says it
> | describes 2.13, is there a newer version?
> 
> To be updated.  We're lacking logistics :)  And BTW, this page should
> be removed now, the official page is at gnu.org.

Sorry. Problably linked from http://sources.redhat.com/autobook/.
 
 
> | Here are the glitches I found so far on the first package I tried,
> | ``freeciv'':
> | 
> | -=-=--
> | 
> |         Output problem:
> | 
> | configure.in:270: error: AC_LANG: unknown language: 
> | aclang.m4:124: _AC_LANG_SET is expanded from...
> | aclang.m4:133: AC_LANG is expanded from...
> | ./aclocal.m4:77: FC_CHECK_X_LIB is expanded from...
> | 
> | 
> | My fix is that checking current LANGUAGE has changed:
> | 
> |         2.13                    2.50
> | 
> |         AC_LANG                 _AC_LANG
> 
> What did you write?  AC_LANG (2.13) and _AC_LANG (2.50) are private to
> Autoconf.  So how come their change has influence on your code?

I don't talk about my program, I talk about "freeciv", as I said.

Apparently the aclocal from freeciv is doing at a time a compare from
AC_LANG to check which default LANGUAGE is in use.

Strange that private vars are accessible, though :-).

 
> | -=-=--
> | 
> |         Output problem:
> | 
> | warning: AC_ARG_PROGRAM invoked multiple times
> | 
> | 
> | Here's offending line in aclocal.m4:
> | 
> | AC_REQUIRE([AC_ARG_PROGRAM])
> | 
> |         Or in configure.in
> | 
> | AC_ARG_PROGRAM
> | 
> | (I removed the one in configure.in...)
> 
> Well, it might be the right choice, depends upon the context.  I
> suppose the AC_REQUIRE you described was *inside* a macro, say
> AM_INIT_AUTOMAKE, in which case what you suggest is Ok.

Right.

 
> | This seemed tolerated with previous version.
> 
> That's a *warning*.  It is still tolerated.

Right - still, warnings command to correct the involved problems.
 

> | 
> | -=-=--
> | 
> |         Output problem:
> | 
> | configure:6483: error: possibly undefined macro: AC_TRY_RUN_NATIVE
> | 
> | 
> | Fixed by looking at your ChangeLog :-) and discovering than I should
> | replace by AC_RUN_IFELSE.
> 
> This would be exposing yourself to future changes too.  It is not
> defined, none of the two you are referring to are documented, and
> therefore are not to be used by users.

So which one should I use, to fix AC_TRY_RUN_NATIVE calls?

 
> I agree it probably means Autoconf does not provide what you need, but
> then, you have to tell us what your needs are, *then*, we'll set up
> the right macro, document it, and *then* guarantee some maintenance in
> the future.

Please note I'm not a developper on this topic, I'm a "packager" whose aim
is to make current packages build with current autoconf. (which is hard -
FYI we've reversed to 2.13 currently)

 
> | -=-=--
> | 
> |         Output problem:
> | 
> | ./configure: line 1638: syntax error: unexpected end of file
> | 
> | 
> | Offending part of configure.in:
> | 
> | AC_CHECK_FUNC(fcntl,
> |               [AC_DEFINE(HAVE_FCNTL)
> |                AC_DEFINE(NONBLOCKING_SOCKETS)],
> |                AC_CHECK_FUNC(ioctl, 
> |                              [AC_DEFINE(HAVE_IOCTL)
> |                               AC_DEFINE(NONBLOCKING_SOCKETS)]))
> | 
> | 
> | Fixed by using:
> | 
> | AC_CHECK_FUNC(fcntl,
> |               [AC_DEFINE(HAVE_FCNTL)
> |                AC_DEFINE(NONBLOCKING_SOCKETS)],
> |               [AC_CHECK_FUNC(ioctl, 
> |                              [AC_DEFINE(HAVE_IOCTL)
> |                               AC_DEFINE(NONBLOCKING_SOCKETS)])])
> | 
> | 
> | 
> | It took me about 30 minutes to find that out... Would it be possible to
> | add some test in autoconf so that it doesn't generate a failing configure
> | when the configure.in contains such broken macros?
> 
> Unfortunately I don't think it is possible.  Or maybe by just catching
> m4 errors...  Hm, good idea, thanks!

Nice :-).


Thanks for your feedback indeed.


-- 
Guillaume Cottenceau - http://mandrakesoft.com/~gc/