Outdated libtool creates trouble on macOS

[Marc Glisse]

On Mon, 21 Aug 2023, Marc Glisse wrote:

> On Mon, 21 Aug 2023, Marc Glisse wrote:
>
>> because SED is used before it is set. I guess AC_PROG_SED might help, but 
>> since all the uses of SED are introduced by autotools, it feels like a bug 
>> that they don't add it automatically.
>
> Ah, that normally happens as part of LT_INIT, and what is broken is that we 
> use some other libtool autoconf macro before LT_INIT. We should move things 
> so GMP_PROG_NM (or at least LT_PATH_NM) is after LT_INIT.
>
> (LT_PATH_NM used to be AC_PROG_NM and not part of libtool I think, so it 
> didn't need this ordering in the past)

Since GMP_PROG_NM/GMP_PROG_AR should be at the same time before and after 
LT_INIT, it will require someone else to deal with that. In the meantime, 
I added AC_PROG_SED before as a workaround, with a FIXME note.

If I run .bootstrap now on shell (freebsd 12.2) after removing 
/home/gmp/usr/bin from my PATH so I get the tools from /usr/local/bin, I 
have a number of errors, but I think that's just because libtool is not installed.

On my laptop (x86_64 debian testing) I have

libtoolize: putting auxiliary files in '.'.
libtoolize: linking file './ltmain.sh'
libtoolize: Consider adding 'AC_CONFIG_MACRO_DIRS([m4])' to configure.ac,
libtoolize: and rerunning libtoolize and aclocal.
libtoolize: Consider adding '-I m4' to ACLOCAL_AMFLAGS in Makefile.am.
configure.ac:2535: warning: The macro `AC_PROG_CC_C99' is obsolete.
configure.ac:2535: You should run autoupdate.
./lib/autoconf/c.m4:1659: AC_PROG_CC_C99 is expanded from...
configure.ac:2535: the top level
configure.ac:2726: warning: The macro `AC_LIBTOOL_WIN32_DLL' is obsolete.
configure.ac:2726: You should run autoupdate.
aclocal.m4:8573: AC_LIBTOOL_WIN32_DLL is expanded from...
configure.ac:2726: the top level
configure.ac:2726: warning: AC_LIBTOOL_WIN32_DLL: Remove this warning and the call to _LT_SET_OPTION when you
configure.ac:2726: put the 'win32-dll' option into LT_INIT's first parameter.
./lib/autoconf/general.m4:2434: AC_DIAGNOSE is expanded from...
aclocal.m4:8573: AC_LIBTOOL_WIN32_DLL is expanded from...
configure.ac:2726: the top level
configure.ac:4048: warning: AC_PROG_LEX without either yywrap or noyywrap is obsolete
./lib/autoconf/programs.m4:716: _AC_PROG_LEX is expanded from...
./lib/autoconf/programs.m4:709: AC_PROG_LEX is expanded from...
aclocal.m4:9499: AM_PROG_LEX is expanded from...
configure.ac:4048: the top level
configure.ac:2534: installing './compile'
configure.ac:81: installing './install-sh'
configure.ac:81: installing './missing'
Makefile.am: installing './COPYING' using GNU General Public License v3 file
Makefile.am:     Consider adding the COPYING file to the version control system
Makefile.am:     for your code, to avoid questions about which license your project uses
configure.ac: installing './ylwrap'
doc/Makefile.am:35: installing 'doc/mdate-sh'
doc/Makefile.am:35: installing 'doc/texinfo.tex'
parallel-tests: installing './test-driver'

So essentially the windows macro (waits until it can be tested), the C99
one (harmless, but can only be removed after increasing AC_PREREQ), and
the others you mentioned. For AC_PROG_LEX, I see in demos/calc/calclex.l
int
yywrap ()
{
   return 1;
}
which I think means that we would be fine with noyywrap, but that's
definitely not something I am familiar with, and again it will require 
increasing AC_PREREQ.


Torbjörn, I think we could start generating the GMP tarballs with newer
autotools at this point (the newer the better, probably).

-- 
Marc Glisse