Re: Outdated libtool creates trouble on macOS
Marc Glisse writes: Do you think we could increase AC_PREREQ to 2.70 (or even 2.71), which would allow a couple more cleanups? I don't think we want to support users rerunning autoconf with an older version than the one we use to generate the tarballs. Sure. Being compatible with older versions than what we use seems quite unnecessary. -- Torbjörn Please encrypt, key id 0xC8601622 ___ gmp-bugs mailing list gmp-bugs@gmplib.org https://gmplib.org/mailman/listinfo/gmp-bugs
Re: Outdated libtool creates trouble on macOS
On Sun, 27 Aug 2023, Torbjörn Granlund wrote: We have been using the default shell.gmplib.org autotools tools for a week now, for generating the public snapshots and the nightbuild snapshots. Things look good. Do you think we could increase AC_PREREQ to 2.70 (or even 2.71), which would allow a couple more cleanups? I don't think we want to support users rerunning autoconf with an older version than the one we use to generate the tarballs. -- Marc Glisse ___ gmp-bugs mailing list gmp-bugs@gmplib.org https://gmplib.org/mailman/listinfo/gmp-bugs
Re: Outdated libtool creates trouble on macOS
Marc Glisse writes: It looks recent enough that the piece of code causing trouble on macOS has been modified. I think we can go with that, we can always upgrade again later if needed. We have been using the default shell.gmplib.org autotools tools for a week now, for generating the public snapshots and the nightbuild snapshots. Things look good. Thanks for this GMP contribution! -- Torbjörn Please encrypt, key id 0xC8601622 ___ gmp-bugs mailing list gmp-bugs@gmplib.org https://gmplib.org/mailman/listinfo/gmp-bugs
Re: Outdated libtool creates trouble on macOS
On Tue, 22 Aug 2023, Torbjörn Granlund wrote: Are the autotools and (just installed) libtool on shell adequate? They are the most recent pre-packaged with FreeBSD. It looks recent enough that the piece of code causing trouble on macOS has been modified. I think we can go with that, we can always upgrade again later if needed. -- Marc Glisse ___ gmp-bugs mailing list gmp-bugs@gmplib.org https://gmplib.org/mailman/listinfo/gmp-bugs
Re: Outdated libtool creates trouble on macOS
Marc Glisse writes: 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. It is now. Torbjörn, I think we could start generating the GMP tarballs with newer autotools at this point (the newer the better, probably). Yes, let's do that! I very much appreciate this effort, BTW! Are the autotools and (just installed) libtool on shell adequate? They are the most recent pre-packaged with FreeBSD. -- Torbjörn Please encrypt, key id 0xC8601622 ___ gmp-bugs mailing list gmp-bugs@gmplib.org https://gmplib.org/mailman/listinfo/gmp-bugs
Re: Outdated libtool creates trouble on macOS
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
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs
Re: Outdated libtool creates trouble on macOS
On Mon, 21 Aug 2023, Marc Glisse wrote: I am a bit confused why this change makes ylwrap appear in am__DIST_COMMON in Makefile.in, but that seems benign enough. Actually, it is running .bootstrap a second time that makes it appear. Not great that it isn't perfectly idempotent, but not too bad. -- Marc Glisse ___ gmp-bugs mailing list gmp-bugs@gmplib.org https://gmplib.org/mailman/listinfo/gmp-bugs
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
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) -- Marc Glisse ___ gmp-bugs mailing list gmp-bugs@gmplib.org https://gmplib.org/mailman/listinfo/gmp-bugs
Re: Outdated libtool creates trouble on macOS
On Mon, 31 Jul 2023, FX Coudert wrote: Hopefully this makes gmp future-proof for at least 10 years in terms of autoconf/automake :) I pushed most of your changes (the windows one will have to wait a bit), thanks. There should not be any regressions with the old autotools. But note that if I generate with new autotools then run configure, I am still seeing the broken behavior checking for BSD- or MS-compatible name lister (nm)... /home/glisse/repos/gmp/configure: line 12165: 1q: command not found /home/glisse/repos/gmp/configure: line 12171: 1q: command not found /home/glisse/repos/gmp/configure: line 12165: 1q: command not found /home/glisse/repos/gmp/configure: line 12171: 1q: command not found /home/glisse/repos/gmp/configure: line 12165: 1q: command not found /home/glisse/repos/gmp/configure: line 12171: 1q: command not found 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. -- Marc Glisse ___ gmp-bugs mailing list gmp-bugs@gmplib.org https://gmplib.org/mailman/listinfo/gmp-bugs
Re: Outdated libtool creates trouble on macOS
On Mon, 31 Jul 2023, FX Coudert wrote: warning: The macro `AC_PROG_CC_C99' is obsolete. This one is only obsolete in autoconf 2.70+, so I am keeping it for now. -- Marc Glisse ___ gmp-bugs mailing list gmp-bugs@gmplib.org https://gmplib.org/mailman/listinfo/gmp-bugs
Re: Outdated libtool creates trouble on macOS
On Sun, 30 Jul 2023, FX Coudert wrote: 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. I am a bit confused why this change makes ylwrap appear in am__DIST_COMMON in Makefile.in, but that seems benign enough. -- Marc Glisse ___ gmp-bugs mailing list gmp-bugs@gmplib.org https://gmplib.org/mailman/listinfo/gmp-bugs
Re: Outdated libtool creates trouble on macOS
FX Coudert writes: > 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. One option to get a kind of windows testing is to cross compile, ./configure --host=x86_64-w64-mingw32 and run tests using wine. On debian, the cross compiler is in the package "gcc-mingw-w64-x86-64-win32". Regards, /Niels -- Niels Möller. PGP key CB4962D070D77D7FCB8BA36271D8F1FF368C6677. Internet email is subject to wholesale government surveillance. ___ 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
On Sun, 30 Jul 2023, FX Coudert wrote: 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 I checked, there is no change in the generated files, so I pushed it. 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. Yes. But probably not this week for me, my holidays are just starting :-) -- Marc Glisse ___ gmp-bugs mailing list gmp-bugs@gmplib.org https://gmplib.org/mailman/listinfo/gmp-bugs
Re: Outdated libtool creates trouble on macOS
FX Coudert writes: 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. If you, Marc, can take a look at those proposed changes, I think they should be applied to the head gmp repo, not the gmp-6.3 one. Currently and for another week, the nightly builds whack gmp-6.3, then we will switch to the head repo. That will then be a broad test of any configure changes. (After that, we can consider merging the changes to gmp-6.3 for inclusion in a 6.3.1.) -- Torbjörn Please encrypt, key id 0xC8601622 ___ gmp-bugs mailing list gmp-bugs@gmplib.org https://gmplib.org/mailman/listinfo/gmp-bugs
Re: Outdated libtool creates trouble on macOS
FX Coudert writes: 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? Github is firewalled off in its entirety. The firewall cannot inspect packets to make more fine-grained decisions. Encryption prevents that. I have no grudge against github, but also don't have time for people or organisations who create interruptions. Implementing some access restrictions in the web server (i.e., not in the firewall) is not worth the added complexity. (There is not company or organisations behind GMP. I fund the infrastructure from my salary, and I and three other volunteers keep developing it.) -- Torbjörn Please encrypt, key id 0xC8601622 ___ 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
On Sun, 30 Jul 2023, FX Coudert wrote: 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? First, a large number of warnings can be a bit scary. Then, when I run configure, I get errors like configure: line 12166: 1q: command not found because configure put some uses of $SED before the code that sets the variable SED. I tried autoupdate, as suggested by the warnings, but it replaced AC_LIBTOOL_WIN32_DLL with something non-functional IIRC. It is likely that these issues and others are not too hard to deal with, but I don't have time for that now, and it is easy not to notice some issues that only affect other platforms so it didn't feel safe at the last minute. 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? I don't know, but you can also download from the FSF servers. -- Marc Glisse ___ 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
Re: Outdated libtool creates trouble on macOS
On Sun, 30 Jul 2023, FX Coudert wrote:
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?
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. Since we wanted a release because of a number of other
improvements, it was safer to stick to the old ones (no worse than the
previous release). I hope we can update for the next release.
If a pro of autotools wants to give a hand...
--
Marc Glisse
___
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
