Re: Do not remove MinGW libraries from Fortran default linker flags

I hope it is ok to CC Paul Eggert who applied the patch that broke
this as far as I understand=2E

Is the change below acceptable?

It is needed when building Octave targeting Windows=2E Without it, the
implementation of `casin` from the Windows runtime is used instead of the
replacement from MinGW-w64=2E
That means that results for the `casin` function are wrong without
that change=2E

Markus


Rebased on the current head of the master branch:


[PATCH] Keep "-lmingwex" and "-lmoldname" in linker flags for MinGW

* lib/autoconf/fortran=2Em4: Do not remove "-lmingwex" or "-lmoldname"
from the linker flags when targeting MinGW=2E  Removing "-lmingwex" causes
an incorrect linker resolution for functions like "casin" for projects
that consist of Fortran and C++ sources=2E  Removing "-lmoldname" causes
issues for Fortran projects that try to use POSIX-like C functions
without a `_` symbol prefix when targeting MinGW=2E
---
 lib/autoconf/fortran=2Em4 | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/autoconf/fortran=2Em4 b/lib/autoconf/fortran=2Em4
index 75631492=2E=2E0fc7545d 100644
--- a/lib/autoconf/fortran=2Em4
+++ b/lib/autoconf/fortran=2Em4
@@ -666,7 +666,7 @@ while test $[@%:@] !=3D 1; do
 	-lang* | -lcrt*=2Eo | -lc | -lgcc* | -lSystem | -libmil | -little \
 	  |-LANG:=3D* | -LIST:* | -LNO:* | -link)
 	  ;;
-	-lkernel32 | -lmingw* | -lmoldname)
+	-lkernel32)
 	  # Ignore this library only on Windows-like systems=2E
 	  case $host_os in
 	  cygwin* | msys* | mingw* | windows*) ;;
--=20
2=2E44=2E0=2Ewindows=2E1




Am 12=2E Dezember 2024 um 13:42 schrieb "Markus M=C3=BCtzel":
> Stripping `-lmingwex` from the Fortran default linker flags can lead to
> a situation where the first `-lmsvcrt` appears before the first
> `-lmingwex` for a library that consists of Fortran and C++ sources=2E
> That means that the linker picks some functions from the Windows CRT tha=
t
> should instead be picked from `libmingwex=2Ea`=2E
>=20
> It took quite some time to figure out an odd behavior when calling
> `std::asin` with a complex double precision value with a real part large=
r
> than 1=2E0 and an imaginary part of 0=2E0 in such a library=2E
> See also: https://octave=2Ediscourse=2Egroup/t/6026/75
>=20
> Also don't strip `-lmoldname` from these flags because omitting that
> library could result in issues when Fortran code tries to call POSIX-lik=
e
> C functions without a `_` prefix when targeting MinGW=2E
>=20
> The following change fixes these issues by essentially reverting the
> changes from:
> https://lists=2Egnu=2Eorg/r/autoconf-patches/2021-09/msg00000=2Ehtml
>=20
> I'm not sure why `-lkernel32` needs to be removed from the linker flags
> when targeting MinGW=2E But we didn't observe an issue with that, so I l=
eft
> that as applied in that changeset=2E
>=20
> diff -urN autoconf-2=2E72/lib/autoconf/fortran=2Em4=2Eorig autoconf-2=2E=
72/lib/autoconf/fortran=2Em4
> --- autoconf-2=2E72/lib/autoconf/fortran=2Em4=2Eorig	2024-10-30 13:31:24=
=2E456674400 +0100
> +++ autoconf-2=2E72/lib/autoconf/fortran=2Em4	2024-12-11 16:08:46=2E4150=
95400 +0100
> @@ -705,7 +705,7 @@
>  	-lang* | -lcrt*=2Eo | -lc | -lgcc* | -lSystem | -libmil | -little \
>  	  |-LANG:=3D* | -LIST:* | -LNO:* | -link)
>  	  ;;
> -	-lkernel32 | -lmingw* | -lmoldname)
> +	-lkernel32)
>  	  # Ignore this library only on Windows-like systems=2E
>  	  case $host_os in
>  	  cygwin* | msys* | mingw* | windows*) ;;
>