Re: gnulib m4/threadlib.m4 bug crashing package tests

[Brian Inglis]

On 2021-12-08 11:49, Achim Gratz wrote:

Achim Gratz writes:

The root cause of this mystery is almost surely in binutils, this area
was touched when they moved the default base address past the 4GiB
boundary (obviously that's a 64bit only change and it only affects PE
targets).  I still have to figure out if I need to pull in a patch from
after the release or revert commits that went into 2.37.



A lengthy git bisect has turned up the offending commit, which was
something that shouldn't obviously interact with weak symbol resolution,
but does. I've reported it upstream…


https://sourceware.org/pipermail/binutils/2021-December/118844.html

hopefully with some prompt response.
As that list seems to be mainly patches, should this be reported at:

https://sourceware.org/bugzilla/buglist.cgi?component=binutils=binutils

Thanks for tracing this issue back to its roots in March:

https://sourceware.org/git/?p=binutils-gdb.git;h=ba6eb62ff0ea9843a018cfd7cd06777bd66ae0a0

+  .debug_loclists ${RELOCATING+BLOCK(__section_alignment__)} 
${RELOCATING+(NOLOAD)} :

+  {
+*(.debug_loclists)
+  }

resulting from:

https://sourceware.org/bugzilla/show_bug.cgi?id=27268

this section is required for Mingw but should not be in Cygwin,
although it was added to all of the below:

$ fgrep -LR .debug_loclists cygwin-??/usr/*86*/lib/ldscripts/
$ lx cygwin-??/usr/*86*/lib/ldscripts/
cygwin-32/usr/i686-pc-cygwin/lib/ldscripts/:
i386pe.x   i386pe.xa   i386pe.xbn   i386pe.xe   i386pe.xn   i386pe.xr 
i386pe.xu
i386pep.x  i386pep.xa  i386pep.xbn  i386pep.xe  i386pep.xn  i386pep.xr 
i386pep.xu


cygwin-64/usr/i686-w64-mingw32/lib/ldscripts/:
i386pe.x   i386pe.xa   i386pe.xbn   i386pe.xe   i386pe.xn   i386pe.xr 
i386pe.xu
i386pep.x  i386pep.xa  i386pep.xbn  i386pep.xe  i386pep.xn  i386pep.xr 
i386pep.xu


cygwin-64/usr/x86_64-pc-cygwin/lib/ldscripts/:
i386pe.x   i386pe.xa   i386pe.xbn   i386pe.xe   i386pe.xn   i386pe.xr 
i386pe.xu
i386pep.x  i386pep.xa  i386pep.xbn  i386pep.xe  i386pep.xn  i386pep.xr 
i386pep.xu


cygwin-64/usr/x86_64-w64-mingw32/lib/ldscripts/:
i386pe.x   i386pe.xa   i386pe.xbn   i386pe.xe   i386pe.xn   i386pe.xr 
i386pe.xu
i386pep.x  i386pep.xa  i386pep.xbn  i386pep.xe  i386pep.xn  i386pep.xr 
i386pep.xu


--
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
[Data in binary units and prefixes, physical quantities in SI.]

Re: gnulib m4/threadlib.m4 bug crashing package tests

[Achim Gratz]

Achim Gratz writes:
> The root cause of this mystery is almost surely in binutils, this area
> was touched when they moved the default base address past the 4GiB
> boundary (obviously that's a 64bit only change and it only affects PE
> targets).  I still have to figure out if I need to pull in a patch from
> after the release or revert commits that went into 2.37.

A lengthy git bisect has turned up the offending commit, which was
something that shouldn't obviously interact with weak symbol resolution,
but does.  I've reported it upstream…


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Wavetables for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldUserWavetables

Re: gnulib m4/threadlib.m4 bug crashing package tests

[Achim Gratz]

Brian Inglis writes:
> The problem with Cygwin weak symbols is apparently that ld expects
> there to be a runtime dynamic loader to resolve NULL weak dynamic
> library references, but unlike ELF neither Cygwin nor Windows does so,
> and PE may not retain the information to do so, or this project would
> likely have done so.

No, that part is well understood since more than a decade when that
problem first hit, the actual problem is that such symbols no
longer resolve to 0x0 on 64bit.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptations for Waldorf Q V3.00R3 and Q+ V3.54R2:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

Re: gnulib m4/threadlib.m4 bug crashing package tests

[Achim Gratz]

Ken Brown via Cygwin-apps writes:
> You're right, I was wrong.  Here's the gnulib test program for anyone
> else who wants to look at this:
>
> #include 
> #pragma weak fputs
> int main ()
> {
>   return (fputs == NULL);
> }
>
> As you said, this used to return 1, but now it returns 0 on 64-bit.

The root cause of this mystery is almost surely in binutils, this area
was touched when they moved the default base address past the 4GiB
boundary (obviously that's a 64bit only change and it only affects PE
targets).  I still have to figure out if I need to pull in a patch from
after the release or revert commits that went into 2.37.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Wavetables for the Terratec KOMPLEXER:
http://Synth.Stromeko.net/Downloads.html#KomplexerWaves

Re: gnulib m4/threadlib.m4 bug crashing package tests

[Brian Inglis]

On 2021-11-28 09:23, Achim Gratz wrote:

Achim Gratz writes:

I'd rather know why the bleeping heck the test suddenly succeeds when it
clearly doesn't actually work.  In other words, I think the linker
should complain, but since it obviously did that before Cygwin 3.2.0 and
not after, something must have changed somewhere that prevent s it from
doing that.


So the exact same problem was discussed in 2010 and the test that's
still there conceived that checks if the returned symbol for weakly
defined fputs is NULL (which would then disable weak symbols for
gnulib).  That obviously still happens on 32bit, but no longer on 64bit.
I think the test is bogus in both cases since the executable will always
be linked again cygwin1.dll and so should be able to resolve the symbol
either way.


Bruno Haible (gnulib maintainer) also patched the current gnulib on 
request from Akim Demaille (bison maintainer).


The problem with Cygwin weak symbols is apparently that ld expects there 
to be a runtime dynamic loader to resolve NULL weak dynamic library 
references, but unlike ELF neither Cygwin nor Windows does so, and PE 
may not retain the information to do so, or this project would likely 
have done so.


--
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
[Data in binary units and prefixes, physical quantities in SI.]

Re: gnulib m4/threadlib.m4 bug crashing package tests

[Ken Brown via Cygwin-apps]

On 11/28/2021 11:33 AM, Achim Gratz wrote:

Ken Brown via Cygwin-apps writes:

It's gnulib that changed, not Cygwin or gcc/binutils.  This is
actually an old issue:

   https://cygwin.com/pipermail/cygwin/2010-April/186342.html


I've built the exact same package (man-db) this Febrary without that
problem and now again with that problem (it doesn't help that the test
suite never actually runs the failing executable).  The gnulib test
failed (as it still does on 32bit) for 64bit in February, but succeeds
(resulting in gnulib trying to use weak symbols) now.


You're right, I was wrong.  Here's the gnulib test program for anyone else who 
wants to look at this:


#include 
#pragma weak fputs
int main ()
{
  return (fputs == NULL);
}

As you said, this used to return 1, but now it returns 0 on 64-bit.  Running 
under gdb I see


(gdb) p fputs
$1 = {int (const char * restrict, FILE * restrict)} 0x1801b0540 

This is a change, and it's actually what one would expect.  But, as Dave Korn 
explained in


  https://cygwin.com/pipermail/cygwin/2010-April/186350.html ,

it doesn't mean that weak symbols on Cygwin behave the way they do on ELF 
platforms.  So I agree with you that this is a bogus test.


Ken

Re: gnulib m4/threadlib.m4 bug crashing package tests

[Achim Gratz]

Ken Brown via Cygwin-apps writes:
> It's gnulib that changed, not Cygwin or gcc/binutils.  This is
> actually an old issue:
>
>   https://cygwin.com/pipermail/cygwin/2010-April/186342.html

I've built the exact same package (man-db) this Febrary without that
problem and now again with that problem (it doesn't help that the test
suite never actually runs the failing executable).  The gnulib test
failed (as it still does on 32bit) for 64bit in February, but succeeds
(resulting in gnulib trying to use weak symbols) now.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Waldorf MIDI Implementation & additional documentation:
http://Synth.Stromeko.net/Downloads.html#WaldorfDocs

Re: gnulib m4/threadlib.m4 bug crashing package tests

[Achim Gratz]

Achim Gratz writes:
> I'd rather know why the bleeping heck the test suddenly succeeds when it
> clearly doesn't actually work.  In other words, I think the linker
> should complain, but since it obviously did that before Cygwin 3.2.0 and
> not after, something must have changed somewhere that prevent s it from
> doing that.

So the exact same problem was discussed in 2010 and the test that's
still there conceived that checks if the returned symbol for weakly
defined fputs is NULL (which would then disable weak symbols for
gnulib).  That obviously still happens on 32bit, but no longer on 64bit.
I think the test is bogus in both cases since the executable will always
be linked again cygwin1.dll and so should be able to resolve the symbol
either way.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Wavetables for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldUserWavetables

Re: gnulib m4/threadlib.m4 bug crashing package tests

[Ken Brown via Cygwin-apps]

On 11/28/2021 10:42 AM, Achim Gratz wrote:

Yaakov Selkowitz via Cygwin-apps writes:

For anyone else who bumps into this, gdb and strace are of no use in
debugging this crash.  I finally thought to look at the stackdump
file, and the second address from the top was in a gnulib file.  That
was the key clue.


Add gl_cv_have_weak=no to cygconf?


I'd rather know why the bleeping heck the test suddenly succeeds when it
clearly doesn't actually work.  In other words, I think the linker
should complain, but since it obviously did that before Cygwin 3.2.0 and
not after, something must have changed somewhere that prevent s it from
doing that.


It's gnulib that changed, not Cygwin or gcc/binutils.  This is actually an old 
issue:


  https://cygwin.com/pipermail/cygwin/2010-April/186342.html

Ken

Re: gnulib m4/threadlib.m4 bug crashing package tests

[Achim Gratz]

Yaakov Selkowitz via Cygwin-apps writes:
>> For anyone else who bumps into this, gdb and strace are of no use in
>> debugging this crash.  I finally thought to look at the stackdump
>> file, and the second address from the top was in a gnulib file.  That
>> was the key clue.
>
> Add gl_cv_have_weak=no to cygconf?

I'd rather know why the bleeping heck the test suddenly succeeds when it
clearly doesn't actually work.  In other words, I think the linker
should complain, but since it obviously did that before Cygwin 3.2.0 and
not after, something must have changed somewhere that prevent s it from
doing that.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf rackAttack:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

Re: gnulib m4/threadlib.m4 bug crashing package tests

[Ken Brown via Cygwin-apps]

On 11/26/2021 12:34 PM, Brian Inglis wrote:

On 2021-11-26 06:08, Ken Brown via Cygwin-apps wrote:

On 11/25/2021 1:25 PM, Yaakov Selkowitz via Cygwin-apps wrote:

Add gl_cv_have_weak=no to cygconf?


Are you suggesting maintainers should do this, or are you talking about 
patching cygport, like this:


diff --git a/cygclass/autotools.cygclass b/cygclass/autotools.cygclass
index 712f437..8b6fdde 100644
--- a/cygclass/autotools.cygclass
+++ b/cygclass/autotools.cygclass
@@ -735,6 +735,14 @@ cygconf() {
 export ac_cv_func_mmap_fixed_mapped=yes ;;
 esac

+   # Some versions of gnulib's threadlib.m4:gl_WEAK_SYMBOLS
+   # incorrectly report that Cygwin supports weak symbols.  See
+   # https://cygwin.com/pipermail/cygwin-apps/2021-September/041587.html.
+   case ${CHOST} in
+   *-*-cygwin*)
+   export gl_cv_have_weak=no ;;
+   esac
+
 # packages that use intltool w/o glib-gettext get this wrong
 export DATADIRNAME="share"


Normally in a regular/autotools build the maintainer appends these overrides to:

 CYGCONF_ARGS=...gl_cv_have_weak=guessing\ no

or to:

src_compile() {
     cd ${S}
     cygautoreconf
     cd ${B}
 cygconf ... gl_cv_have_weak=guessing\ no
     cygmake
}


cygport already does this for ac_cv_func_mmap_fixed_mapped.  That's why I asked 
Yaakov to clarify what he had in mind.


Ken

Re: gnulib m4/threadlib.m4 bug crashing package tests

[Brian Inglis]

On 2021-11-26 06:08, Ken Brown via Cygwin-apps wrote:

On 11/25/2021 1:25 PM, Yaakov Selkowitz via Cygwin-apps wrote:

Add gl_cv_have_weak=no to cygconf?


Are you suggesting maintainers should do this, or are you talking about 
patching cygport, like this:


diff --git a/cygclass/autotools.cygclass b/cygclass/autotools.cygclass
index 712f437..8b6fdde 100644
--- a/cygclass/autotools.cygclass
+++ b/cygclass/autotools.cygclass
@@ -735,6 +735,14 @@ cygconf() {
     export ac_cv_func_mmap_fixed_mapped=yes ;;
     esac

+   # Some versions of gnulib's threadlib.m4:gl_WEAK_SYMBOLS
+   # incorrectly report that Cygwin supports weak symbols.  See
+   # 
https://cygwin.com/pipermail/cygwin-apps/2021-September/041587.html.

+   case ${CHOST} in
+   *-*-cygwin*)
+   export gl_cv_have_weak=no ;;
+   esac
+
     # packages that use intltool w/o glib-gettext get this wrong
     export DATADIRNAME="share"


Normally in a regular/autotools build the maintainer appends these 
overrides to:


CYGCONF_ARGS=...gl_cv_have_weak=guessing\ no

or to:

src_compile() {
cd ${S}
cygautoreconf
cd ${B}
cygconf ... gl_cv_have_weak=guessing\ no
cygmake
}

--
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
[Data in binary units and prefixes, physical quantities in SI.]

Re: gnulib m4/threadlib.m4 bug crashing package tests

[Ken Brown via Cygwin-apps]

On 11/25/2021 1:25 PM, Yaakov Selkowitz via Cygwin-apps wrote:

Add gl_cv_have_weak=no to cygconf?


Are you suggesting maintainers should do this, or are you talking about patching 
cygport, like this:


diff --git a/cygclass/autotools.cygclass b/cygclass/autotools.cygclass
index 712f437..8b6fdde 100644
--- a/cygclass/autotools.cygclass
+++ b/cygclass/autotools.cygclass
@@ -735,6 +735,14 @@ cygconf() {
export ac_cv_func_mmap_fixed_mapped=yes ;;
esac

+   # Some versions of gnulib's threadlib.m4:gl_WEAK_SYMBOLS
+   # incorrectly report that Cygwin supports weak symbols.  See
+   # https://cygwin.com/pipermail/cygwin-apps/2021-September/041587.html.
+   case ${CHOST} in
+   *-*-cygwin*)
+   export gl_cv_have_weak=no ;;
+   esac
+
# packages that use intltool w/o glib-gettext get this wrong
export DATADIRNAME="share"

Ken

Re: gnulib m4/threadlib.m4 bug crashing package tests

[Brian Inglis]

On 2021-11-25 11:25, Yaakov Selkowitz via Cygwin-apps wrote:

On Thu, 2021-11-25 at 11:26 -0500, Ken Brown via Cygwin-apps wrote:

On 9/29/2021 7:46 PM, Brian Inglis wrote:

There is a gnulib bug in threadlib.m4 from at least serial 29 to serial
31 that incorrectly configures Cygwin support of weak references.

This leads to SIGSEGV stack smashing crashes with no backtrace
@ 0x1 or 0x0005 etc. normally during tests.

Akim Demaille on bug-bison referred the issue to bug-gnulib where
Bruno Haible diagnosed and patched the problem to appear in
m4/threadlib.m4 serial 32:

* m4/threadlib.m4 (gl_WEAK_SYMBOLS): Force a "guessing no" result on
Cygwin
https://lists.gnu.org/archive/html/bug-gnulib/2021-09/msg00068.html
[gl_cv_have_weak="guessing no"]

The patch has now been applied to bison, wget, and wget2, and I
have attached my patches for the copies in those packages, in
case anyone else has this issue in their (mainly GNU) packages
which may incorporate by inclusion recently updated gnulib m4
macros used in autotools builds.


I'm writing to reinforce this warning. I just spent 2 days trying 
to debug mysterious texinfo crashes that were caused by this bug. I

could have saved a lot of time if I had remembered your email and
had checked the gnulib version being used by texinfo.
For anyone else who bumps into this, gdb and strace are of no use 
in debugging this crash. I finally thought to look at the

stackdump file, and the second address from the top was in a gnulib
file. That was the key clue.



Add gl_cv_have_weak=no to cygconf?


or gl_cv_have_weak="guessing no" or
patch [gl_cv_have_weak="guessing no"] above

--
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
[Data in binary units and prefixes, physical quantities in SI.]

Re: gnulib m4/threadlib.m4 bug crashing package tests

[Yaakov Selkowitz via Cygwin-apps]

On Thu, 2021-11-25 at 11:26 -0500, Ken Brown via Cygwin-apps wrote:
> On 9/29/2021 7:46 PM, Brian Inglis wrote:
> > There is a gnulib bug in threadlib.m4 from at least serial 29 to serial
> > 31 that incorrectly configures Cygwin support of weak references.
> > 
> > This leads to SIGSEGV stack smashing crashes with no backtrace
> > @ 0x1 or 0x0005 etc. normally during tests.
> > 
> > Akim Demaille on bug-bison referred the issue to bug-gnulib where
> > Bruno Haible diagnosed and patched the problem to appear in
> > m4/threadlib.m4 serial 32:
> > 
> > * m4/threadlib.m4 (gl_WEAK_SYMBOLS): Force a "guessing no" result on
> > Cygwin
> > https://lists.gnu.org/archive/html/bug-gnulib/2021-09/msg00068.html
> > [gl_cv_have_weak="guessing no"]
> > 
> > The patch has now been applied to bison, wget, and wget2, and I have
> > attached my patches for the copies in those packages, in case anyone
> > else has this issue in their (mainly GNU) packages which may incorporate
> > by 
> > inclusion recently updated gnulib m4 macros used in autotools builds.
> 
> Thanks, Brian.
> 
> I'm writing to reinforce this warning.  I just spent 2 days trying to debug 
> mysterious texinfo crashes that were caused by this bug.  I could have saved
> a 
> lot of time if I had remembered your email and had checked the gnulib
> version 
> being used by texinfo.
> 
> For anyone else who bumps into this, gdb and strace are of no use in
> debugging 
> this crash.  I finally thought to look at the stackdump file, and the second
> address from the top was in a gnulib file.  That was the key clue.

Add gl_cv_have_weak=no to cygconf?

-- 
Yaakov

Re: gnulib m4/threadlib.m4 bug crashing package tests

[Ken Brown via Cygwin-apps]

On 9/29/2021 7:46 PM, Brian Inglis wrote:

There is a gnulib bug in threadlib.m4 from at least serial 29 to serial
31 that incorrectly configures Cygwin support of weak references.

This leads to SIGSEGV stack smashing crashes with no backtrace
@ 0x1 or 0x0005 etc. normally during tests.

Akim Demaille on bug-bison referred the issue to bug-gnulib where
Bruno Haible diagnosed and patched the problem to appear in
m4/threadlib.m4 serial 32:

* m4/threadlib.m4 (gl_WEAK_SYMBOLS): Force a "guessing no" result on Cygwin
https://lists.gnu.org/archive/html/bug-gnulib/2021-09/msg00068.html
[gl_cv_have_weak="guessing no"]

The patch has now been applied to bison, wget, and wget2, and I have
attached my patches for the copies in those packages, in case anyone
else has this issue in their (mainly GNU) packages which may incorporate by 
inclusion recently updated gnulib m4 macros used in autotools builds.


Thanks, Brian.

I'm writing to reinforce this warning.  I just spent 2 days trying to debug 
mysterious texinfo crashes that were caused by this bug.  I could have saved a 
lot of time if I had remembered your email and had checked the gnulib version 
being used by texinfo.


For anyone else who bumps into this, gdb and strace are of no use in debugging 
this crash.  I finally thought to look at the stackdump file, and the second 
address from the top was in a gnulib file.  That was the key clue.


Ken

gnulib m4/threadlib.m4 bug crashing package tests

[Brian Inglis]

There is a gnulib bug in threadlib.m4 from at least serial 29 to serial
31 that incorrectly configures Cygwin support of weak references.

This leads to SIGSEGV stack smashing crashes with no backtrace
@ 0x1 or 0x0005 etc. normally during tests.

Akim Demaille on bug-bison referred the issue to bug-gnulib where
Bruno Haible diagnosed and patched the problem to appear in
m4/threadlib.m4 serial 32:

* m4/threadlib.m4 (gl_WEAK_SYMBOLS): Force a "guessing no" result on Cygwin
https://lists.gnu.org/archive/html/bug-gnulib/2021-09/msg00068.html
[gl_cv_have_weak="guessing no"]

The patch has now been applied to bison, wget, and wget2, and I have
attached my patches for the copies in those packages, in case anyone
else has this issue in their (mainly GNU) packages which may incorporate 
by inclusion recently updated gnulib m4 macros used in autotools builds.


--
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
[Data in binary units and prefixes, physical quantities in SI.]
2021-09-17  Bruno Haible  

threadlib: Avoid crashes in thread-related functions on Cygwin 3.2.0.
Reported by Brian Inglis via Akim Demaille in
.
* m4/threadlib.m4 (gl_WEAK_SYMBOLS): Force a "guessing no" result on
Cygwin.

diff -w --git origsrc/m4/threadlib.m4 src/m4/threadlib.m4
index 37b797c18..6b43bbdfa 100644
--- origsrc/m4/threadlib.m4 2021-08-02 23:51:08.0 -0600
+++ src/m4/threadlib.m4 2021-09-17 15:17:37.103525500 -0600
@@ -1,4 +1,4 @@
-# threadlib.m4 serial 31
+# threadlib.m4 serial 32
 dnl Copyright (C) 2005-2021 Free Software Foundation, Inc.
 dnl This file is free software; the Free Software Foundation
 dnl gives unlimited permission to copy and/or distribute it,
@@ -84,38 +84,48 @@ AC_DEFUN([gl_WEAK_SYMBOLS],
   AC_REQUIRE([AC_CANONICAL_HOST])
   AC_CACHE_CHECK([whether imported symbols can be declared weak],
 [gl_cv_have_weak],
-[gl_cv_have_weak=no
- dnl First, test whether the compiler accepts it syntactically.
- AC_LINK_IFELSE(
-   [AC_LANG_PROGRAM(
-  [[extern void xyzzy ();
+[case "$host_os" in
+   cygwin*)
+ dnl On Cygwin 3.2.0 with gcc 10.2, the test below would succeed, but
+ dnl programs that use pthread_in_use() with weak symbol references
+ dnl crash miserably at runtime.
+ gl_cv_have_weak="guessing no"
+ ;;
+   *)
+ gl_cv_have_weak=no
+dnl First, test whether the compiler accepts it syntactically.
+AC_LINK_IFELSE(
+  [AC_LANG_PROGRAM(
+ [[extern void xyzzy ();
 #pragma weak xyzzy]],
-  [[xyzzy();]])],
-   [gl_cv_have_weak=maybe])
- if test $gl_cv_have_weak = maybe; then
-   dnl Second, test whether it actually works. On Cygwin 1.7.2, with
-   dnl gcc 4.3, symbols declared weak always evaluate to the address 0.
-   AC_RUN_IFELSE(
- [AC_LANG_SOURCE([[
+ [[xyzzy();]])],
+  [gl_cv_have_weak=maybe])
+if test $gl_cv_have_weak = maybe; then
+  dnl Second, test whether it actually works. On Cygwin 1.7.2, with
+  dnl gcc 4.3, symbols declared weak always evaluate to the address 0.
+  AC_RUN_IFELSE(
+[AC_LANG_SOURCE([[
 #include 
 #pragma weak fputs
 int main ()
 {
   return (fputs == NULL);
 }]])],
- [gl_cv_have_weak=yes],
- [gl_cv_have_weak=no],
- [dnl When cross-compiling, assume that only ELF platforms support
-  dnl weak symbols.
-  AC_EGREP_CPP([Extensible Linking Format],
-[#ifdef __ELF__
- Extensible Linking Format
- #endif
-],
-[gl_cv_have_weak="guessing yes"],
-[gl_cv_have_weak="guessing no"])
- ])
- fi
+[gl_cv_have_weak=yes],
+[gl_cv_have_weak=no],
+[dnl When cross-compiling, assume that only ELF platforms support
+ dnl weak symbols.
+ AC_EGREP_CPP([Extensible Linking Format],
+   [#ifdef __ELF__
+Extensible Linking Format
+#endif
+   ],
+   [gl_cv_have_weak="guessing yes"],
+   [gl_cv_have_weak="guessing no"])
+])
+fi
+;;
+ esac
  dnl But when linking statically, weak symbols don't work.
  case " $LDFLAGS " in
*" -static "*) gl_cv_have_weak=no ;;
2021-09-17  Bruno Haible  

threadlib: Avoid crashes in thread-related functions on Cygwin 3.2.0.
Reported by Brian Inglis via Akim Demaille in
.
* m4/threadlib.m4 (gl_WEAK_SYMBOLS): Force a "guessing no" result on
Cygwin.

2021-09-27  Brian Inglis  

Original