Re: autoconf-2.50 issues...

[Akim Demaille]

| Hi,

Hi,

Please, write to public lists, not to me.

| 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.

| 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.


| 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?

| -=-=--
| 
|         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.

| This seemed tolerated with previous version.

That's a *warning*.  It is still tolerated.

| 
| -=-=--
| 
|         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.

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.


| -=-=--
| 
|         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!



        Akim