cygwin: workaround DLL load address conflict

The DLL load addresses are generated by the linker based on the DLL
names, and 5.39.10 we're getting a conflict between
cygperl5_41_6.dll and Langinfo.dll.

As a workaround, statically link Langinfo into cygperl for CI and
mention the problem in perldelta for anyone else who might build
perl on cygwin

Fixes but should not close #22695

.github/workflows/testsuite.yml

@@ -605,7 +605,7 @@ jobs:
         run: |
           cd ~/work
           set +e
-          ./Configure -des -Dusedevel -Doptimize=-g -DDEBUGGING || exit 1
+          ./Configure -des -Dusedevel -Doptimize=-g -DDEBUGGING -Astatic_ext=I18N/Langinfo || exit 1
       - name: Build
         shell: sh
         env:

pod/perldelta.pod

@@ -382,7 +382,22 @@ platform specific bugs also go here.
 
 =item *
 
-XXX
+C<cygwin> builds may fail during testing due to a conflict between the
+load addresses of F<cygperl5_41_6.dll> and
+F<olib/auto/I18N/Langinfo/Langinfo.dll>.  This will also be visible
+for anything that attempts to fork() with C<I18N::LangInfo> loaded.
+
+This is known to fail for builds with options that increase the size
+of the binary, such as C<-DDEBUGGING>, C<-Doptimize="-O0 -g"> or
+C<-Doptimize="-O2 -g -march=x86-64-v2">.
+
+This can be avoided by building perl with
+C<-Astatic_ext=I18N/Langinfo>.
+
+The base addresses are generated by the linker based on the names of
+the DLLs, so this is expected to clear up for 5.41.7.
+
+[github #22695]
 
 =back