[Mingw-w64-public] Default library order breaks backward compatibility with older versions of Windows

[Christian F. <Chr...@t-...>]

For some unknown reason, certain functions from advapi32.dll are now 
also exported by the kernel32.dll of recent Windows versions. To provide 
backward compatibility, -ladvapi32 must occur before -lkernel32 in the 
linker command, but this is not the case by default:

Testcase with current packages from Cygwin (10.0.0-1, GCC 11.2.0-1):

$ cat testdll.c
#include <windows.h>
int (*fp)() = CreateProcessAsUserA;
int main() { return 42; }

$ x86_64-w64-mingw32-gcc -o testdll1 testdll.c

$ x86_64-w64-mingw32-gcc -o testdll2 testdll.c -ladvapi32

$ objdump -p testdll1.exe | egrep 'DLL Name|CreateProcessAsUserA'
         DLL Name: KERNEL32.dll
         82ac      235  CreateProcessAsUserA
         DLL Name: msvcrt.dll

$ objdump -p testdll2.exe | egrep 'DLL Name|CreateProcessAsUserA'
         DLL Name: ADVAPI32.dll
         82d0     1138  CreateProcessAsUserA
         DLL Name: KERNEL32.dll
         DLL Name: msvcrt.dll

Both work on Win10, but only testdll2 works on Win7.

The root of the problem is that the libgcc rule in the specs contains 
another -lkernel32:

$ x86_64-w64-mingw32-gcc -dumpspecs
...
*lib:
... -ladvapi32 -lshell32 -luser32 -lkernel32
...
*libgcc:
... -lmoldname -lmingwex -lmsvcrt -lkernel32
...

This -lkernel32 prepends the -ladvapi32 from the lib rule:

$ x86_64-w64-mingw32-gcc -o testdll1 testdll.c -v
...
/usr/lib/.../11/collect2.exe ... -lkernel32 ... -ladvapi32 ... 
-lkernel32 ...


A modified specs file with '... -ladvapi32 -lkernel32' in the libgcc 
rule would fix the problem.

I could add a report to gcc bugzilla if desired.

Regards,
Christian