Re: Outdated libtool creates trouble on macOS
> 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. I was just arriving at the same conclusion, from my own testing. FX ___ gmp-bugs mailing list gmp-bugs@gmplib.org https://gmplib.org/mailman/listinfo/gmp-bugs
Re: Outdated libtool creates trouble on macOS
OK, final patch. This was the most painful, because I hate autoconf quoting, way too many brackets and parentheses. But the patch silences the remaining warnings about AC_TRY_COMPILE, AC_TRY_LINK, and AC_TRY_RUN. And it is verified to be a no-op in terms of the generated configure file (except the one comment changed on purpose, and one extraneous newline character removed). Hopefully this makes gmp future-proof for at least 10 years in terms of autoconf/automake :) The remaining warnings are: > glibtoolize: Consider adding 'AC_CONFIG_MACRO_DIRS([m4])' to configure.ac, > glibtoolize: and rerunning glibtoolize and aclocal. > glibtoolize: Consider adding '-I m4' to ACLOCAL_AMFLAGS in Makefile.am. which is perfectly safe to ignore (it’s just advice). And this: > configure.ac:4045: 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:9472: AM_PROG_LEX is expanded from... > configure.ac:4045: the top level which is also safe to ignore. I tried to silence it, but did not find a way: AM_PROG_LEX does not accept an extra argument, and switching from AM_PROG_LEX to AC_PROG_LEX would introduce a functional change. I’m not sure if the change would risk breaking some platforms for gmp with exotic flex implementations, so I did not want to risk it. I have filed the issue with automake, asking for their opinion on what I think is a automake / autoconf feature mismatch. Cheers, FX ac_try.diff Description: Binary data ___ gmp-bugs mailing list gmp-bugs@gmplib.org https://gmplib.org/mailman/listinfo/gmp-bugs
Re: Outdated libtool creates trouble on macOS
Fifth batch, fixing the following:
warning: back quotes and double quotes must not be escaped in:
$as_me:${as_lineno-$LINENO}: WARNING: the \"none\" host is obsolete, use
--disable-assembly
warning: back quotes and double quotes must not be escaped in: $as_me: WARNING:
the \"none\" host is obsolete, use --disable-assembly
warning: AC_OUTPUT should be used without arguments.
Almost there…
FX
batch5.diff
Description: Binary data
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs
Re: Outdated libtool creates trouble on macOS
> No problem, I’ll continue to post small batches of changes here when I get
> some time.
Fourth patch in the series, dealing with win32 DLL’s. You said you had issues
with this before, I implemented the changes recommended by the manual (and did
not use autoupdate, which is not always reliable in my experience).
From the generated files, it seems OK: the only effect is a change in the
position of some code. Still, it needs to be tested on Windows, and I don’t
have access to such machines. If there are failures, an alternative would be to
move up the call to "LT_INIT([win32-dll])” to where AC_LIBTOOL_WIN32_DLL
previously was called.
Best,
FX
win32.diff
Description: Binary data
PS: for the record, after this is done, only the following remain:
warning: back quotes and double quotes must not be escaped in:
$as_me:${as_lineno-$LINENO}: WARNING: the \"none\" host is obsolete, use
--disable-assembly
warning: back quotes and double quotes must not be escaped in: $as_me: WARNING:
the \"none\" host is obsolete, use --disable-assembly
warning: AC_OUTPUT should be used without arguments.
warning: AC_PROG_LEX without either yywrap or noyywrap is obsolete
warning: The macro `AC_TRY_COMPILE' is obsolete.
warning: The macro `AC_TRY_LINK' is obsolete.
warning: The macro `AC_TRY_RUN' is obsolete.
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs
Re: Outdated libtool creates trouble on macOS
> Yes. But probably not this week for me, my holidays are just starting :-) No problem, I’ll continue to post small batches of changes here when I get some time. Third batch of changes, dealing with the following: warning: The macro `AC_CHECK_LIBM' is obsolete. warning: The macro `AC_PROG_CC_C99' is obsolete. warning: The macro `AC_PROG_LIBTOOL' is obsolete. warning: The macro `AC_PROG_NM' is obsolete. warning: The macro `AC_TYPE_SIGNAL' is obsolete. These obsolescences are part of the wider move to consider that C89 (or ANSI C) is always available. They have been in autoconf since 2012. FX batch3.diff Description: Binary data ___ gmp-bugs mailing list gmp-bugs@gmplib.org https://gmplib.org/mailman/listinfo/gmp-bugs
Re: Outdated libtool creates trouble on macOS
PS: second patchlet, to deal with these two macros: > warning: The macro `AC_HEADER_STDC' is obsolete. > warning: The macro `AC_HEADER_TIME' is obsolete. time.diff Description: Binary data ___ gmp-bugs mailing list gmp-bugs@gmplib.org https://gmplib.org/mailman/listinfo/gmp-bugs
Re: Outdated libtool creates trouble on macOS
> First, a large number of warnings can be a bit scary.
Attached is a diff that fixes most of the warnings. It does three things:
- raise autoconf requirement to 2.69 (released in 2012, and what you already
use currently for production of the tarballs)
- replaces AC_FD_CC with AS_MESSAGE_LOG_FD, its new name
- replaces AC_HELP_STRING with AS_HELP_STRING, its new name
Once this is done, the number of warnings becomes reasonable:
> glibtoolize: Consider adding 'AC_CONFIG_MACRO_DIRS([m4])' to configure.ac,
> glibtoolize: and rerunning glibtoolize and aclocal.
> glibtoolize: Consider adding '-I m4' to ACLOCAL_AMFLAGS in Makefile.am.
>
> warning: back quotes and double quotes must not be escaped in:
> $as_me:${as_lineno-$LINENO}: WARNING: the \"none\" host is obsolete, use
> --disable-assembly
> warning: back quotes and double quotes must not be escaped in: $as_me:
> WARNING: the \"none\" host is obsolete, use --disable-assembly
> warning: AC_LIBTOOL_WIN32_DLL: Remove this warning and the call to
> _LT_SET_OPTION when you put the 'win32-dll' option into LT_INIT's first
> parameter.
> warning: AC_OUTPUT should be used without arguments.
> warning: AC_PROG_LEX without either yywrap or noyywrap is obsolete
> warning: The macro `AC_CHECK_LIBM' is obsolete.
> warning: The macro `AC_HEADER_STDC' is obsolete.
> warning: The macro `AC_HEADER_TIME' is obsolete.
> warning: The macro `AC_LIBTOOL_WIN32_DLL' is obsolete.
> warning: The macro `AC_PROG_CC_C99' is obsolete.
> warning: The macro `AC_PROG_LIBTOOL' is obsolete.
> warning: The macro `AC_PROG_NM' is obsolete.
> warning: The macro `AC_TRY_COMPILE' is obsolete.
> warning: The macro `AC_TRY_LINK' is obsolete.
> warning: The macro `AC_TRY_RUN' is obsolete.
> warning: The macro `AC_TYPE_SIGNAL' is obsolete.
I’ll try to have a look: it would be good to contribute those changes early, so
there is ample testing before a future release, as you said.
FX
macro_rename.diff
Description: Binary data
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs
Re: Outdated libtool creates trouble on macOS
Hi Marc, > Sorry about that. I knew there were problems with old autotools and quickly > tried updating them before the release, but that caused too many problems. What are the problems? Our workaround is to rerun the latest autoreconf, and it emits a lot of warnings, but it does not create trouble. What are the symptoms you are seeing? > If a pro of autotools wants to give a hand… Can help if you let me know what you need. One other question: our Linux builder, which is running from Github Actions, fails to download from gmplib.org I thought only the mercurial repo was firewalled, is that not the case? Best, FX ___ gmp-bugs mailing list gmp-bugs@gmplib.org https://gmplib.org/mailman/listinfo/gmp-bugs
Outdated libtool creates trouble on macOS
Hi,
Compilation of newly released GMP 6.3.0 on macOS (both Intel and ARM) leads to
wrongly compiled libraries, with a flat namespace. This is generally avoided
(and enforced by various build tools) on macOS since many OS versions, because
it can cause linker errors due to name collisions.
The reason for this is this hunk in the configure script:
> darwin*) # darwin 5.x on
> # if running on 10.5 or later, the deployment target defaults
> # to the OS version, if on x86, and 10.4, the deployment
> # target defaults to 10.4. Don't you love it?
> case ${MACOSX_DEPLOYMENT_TARGET-10.0},$host in
> 10.0,*86*-darwin8*|10.0,*-darwin[91]*)
> _lt_dar_allow_undefined='$wl-undefined ${wl}dynamic_lookup' ;;
> 10.[012][,.]*)
> _lt_dar_allow_undefined='$wl-flat_namespace $wl-undefined
> ${wl}suppress' ;;
> 10.*)
> _lt_dar_allow_undefined='$wl-undefined ${wl}dynamic_lookup' ;;
> esac
This was generated by an autoconf, which relies on an outdated libtool version.
This was fixed in libtool by
https://git.savannah.gnu.org/cgit/libtool.git/commit/?id=9e8c882517082fe5755f2524d23efb02f1522490
(which is included in latest release, version 2.4.7).
Would it be possible to release the next version with more recent
autoconf/libtool combo?
Thanks,
FX Coudert
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs
