AFAIU, gpgrt-config works well now for the multilib MinGW target.

Pushed.

Should be OK for mingw.org's MinGW. I cannot test the MinGW64 bits, but I trust that you did.

I encountered this issue of struct stat when compiling for x86_64 of Windows.
I'm considering this patch:

diff --git a/common/sysutils.c b/common/sysutils.c
index c30f9a0ce..bbed309a8 100644
--- a/common/sysutils.c
+++ b/common/sysutils.c
@@ -1237,10 +1237,20 @@ int
 gnupg_stat (const char *name, struct stat *statbuf)
 {
 # ifdef HAVE_W32_SYSTEM
+#  if __MINGW32_MAJOR_VERSION > 3
+    /* mingw.org's MinGW */
+#   define STRUCT_STAT _stat
+#  elif defined(_USE_32BIT_TIME_T)
+    /* MinGW64 for i686 */
+#   define STRUCT_STAT _stat32
+#  else
+    /* MinGW64 for x86_64 */
+#   define STRUCT_STAT _stat64i32
+#  endif
   if (any8bitchar (name))
     {
       wchar_t *wname;
-      struct _stat32 st32;
+      struct STRUCT_STAT st32;
       int ret;

Pushed the changes for http.c.

GCC 11.3 and GCC 12.1 are out with the fix.

Last part is applied. Let me consider how to solve, for other parts.

I guess I don't understand what you mean by "native building". This build was with MinGW, which is as "native" as MinGW64 is.
The reason for the problem is (AFAIU) that MinGW64 went after Microsoft's change in stat due to the 32-bit vs 64-bit time and off_t values issue.s That change breaks backward compatibility in more than one way: programs compiled on some versions of Windows will not run on other versions. mingw.org's MinGW kept the original semantics and symbols, which is why _stat32 exists in the mingw.org's headers, but is not exposed by default.

Turned into a feature request because native building on Windows is not supported.

Bison used to be the de-facto standard yacc ;-)

I think that a simple way is defining a table (string -> token) by ourselves in yylex, not enabling %token-table.
(Then, we don't need to depend on the feature of string with %token, which is not supported by POSIX yacc.)

Thanks for your findings. I recall that I read this in the announcement and cursed about this new tendency in GNU to break long standing APIs.

Looks like yytoknum was removed from Bison in version 3.8: http://git.savannah.gnu.org/cgit/bison.git/commit/?id=1efe31185ff6b0bc22ff527098971bedf1ace5f4

Based on GCC bugzilla, affected released GCC versions are 11.1 and 11.2.

(ab | ba) >= 0 is used to make optimization analysis for compiler more difficult. I see that with (ab | ba) == 0, it would be much easier for compiler to conclude than loop could exit early as soon as first a[i] != b[i] is seen.

t-link does not do antthing useful, anyway. I don't think it is justified to add dlopen stuff. Running real test is anyway a manual action; for a full test automation we would need to emulate all supported cards.

the t-link test should dlopen scute.so in runtime rather than link against it in build-time.

As of slibtool commit 9c5ba5eb, scute now builds out of the box. I'd still recommend taking the above into consideration, though.

For what it's worth, scute is in violation of gnu libtool's documentation. Building with gnu libtool:

Done for gpa.
Please test.

Done for pinentry.

In T5394#145082, @werner wrote:

Regarding slibtool: I would actually like to have an easier to maintain tool than libtool (of which we use our own version) for GnuPG related software. However, its requirement "the compiler should support -std=c99" is currently a no-starter for libgcrypt and some other libs.

Sorry to dig up an old thread...

The configure run tells you what libraries are missing - none in your case. However, something is wrong with your development setup: The configure run detected libksba but cc compiler did not found it anymore. Check that you don't have any special envvars set etc. What is the actual compiler command which failed (make sure not to pass V=0 to make for this).

Dear Werner,

Thanks, I try to keep the README always up to date with the debian depenencies as I find this useful myself without running configure multiple times to find all the dependencies.

No question a list like this is bound to be incomplete, but the argument "the README can only tell about those which we don't expect to be installed on a developer's box" does not seem to apply to the other items already on the list. For instance build-essentials and automake are almost certainly on every developers machine already.

There is a message telling you what is missing. Thus I can not consider this a bug. There are just too many dependencies which are required for cross-compiling that the README can only tell about those which we don't expect to be installed on a developer's box.

no, that doesn't change anything.

Does it build if configure with parameter 'ac_cv_sys_symbol_underscore=yes'? <path-to-libgcrypt-source>/configure ac_cv_sys_symbol_underscore=yes --host=aarch64-apple-darwin ...

Compiling now works, but I get the following linker errors:

Does attached patch help?

I tried it - that doesn't help. Same error message.

Problem is in GET_DATA_POINTER macro. MacOS assembler expects data references in some different format than Linux. Could you try following edit and see if libgcrypt then compiles? In cipher/asm-common-aarch64.h, there is definition of GET_DATA_POINTER macro:

#ifdef _WIN32
#define GET_DATA_POINTER(reg, name) \
	adrp    reg, name ; \
	add     reg, reg, #:lo12:name ;
#else
#define GET_DATA_POINTER(reg, name) \
	adrp    reg, :got:name ; \
	ldr     reg, [reg, #:got_lo12:name] ;
#endif

I have now tried to build libgcrypt 1.9.0 for arm64 using clang. I get the following error:

OK, then we'll have to live with --disable-asm until the next major version is released, or switch to gcc.

We should not do this.

AArch64 clang support was added to 'master' on 2018-03-28. One would need to backport commits 8ee38806245ca8452051b1a245f44082323f37f6...9b58e4a03ba3aeff7bae3f40da706977870c9649 to 1.8 branch.

In T5157#139622, @gniibe wrote:

ARM64 has been only tested on platforms which support ELF.

While it doesn't looks good (using AMD64 even if it's ARM64), I think this patch should be applied:

diff --git a/cipher/asm-common-aarch64.h b/cipher/asm-common-aarch64.h
...

For macOS, with SIP, some program like libgcrypt/tests/random fails, because the hack for DYLD_LIBRARY_PATH by libtool doesn't work for child process:
https://developer.apple.com/library/archive/documentation/Security/Conceptual/System_Integrity_Protection_Guide/RuntimeProtections/RuntimeProtections.html

Another issue that comes in to mind is that current ARM/ARM64 HW feature detection most likely wont work on MacOS. Thus HW accelerated AES&SHA&GHASH implementation wont be used.

HAVE_COMPATIBLE_GCC_AMD64_PLATFORM_AS is never defined on ARM64 as it depends on "$mpi_cpu_arch" == "x86". Instead I think new check for GCC assembly ELF directives would be needed in configure.ac, similar to HAVE_GCC_ASM_CFI_DIRECTIVES check. Following check should work, but I have not yet tested it:

ARM64 has been only tested on platforms which support ELF.

Yes, I did. Identical result.

Why the hell do they that? The standard compiler on a system is called cc which may translated to whatever the system installs for it. gcc is a specific implementation with certain properties. Di you try CC=clang to override this?

And the arm64 cross-compiler:

Sorry, I forgot to mention that Apple ships a gcc-wrapper for clang. It just accepts gcc command lines parameters and translates them to clang parameters.
Here is the output of gcc --version:

You say that you build using clang but the log shows that you invoke gcc.

No, c99 was never required. Meanwhile we use a few c99 features but those are supported without any compiler option.

-std=c99 is probably the reason that the tests fail.

Please try with out supplied CFLAGS or change them from

No info received

Yeah, this can be done.

Building with -fno-common now works for me on 2.2 and master. Thanks for the patch.

I took your patch but modified it to define EXTERN_UNLESS_MAIN_MODULE only at one place.

It has been fixed in the repo for nearly a year, see T4459. A new release is urgently required and will follow in the next days. I close this as a duplicate.

In a private mail someone else reported a similar problems and explained that gcc-10 will change the default from -fcommon to -fno-common. I think this is again a bad move in compiler development. Replacing the de-facto standard C compiler behaviour with something _allowed_ by ISO-C. No industrial grade toolchain would ever do such a silly default change - too many customers would rightfully be angry with them.

For what I use, please refer: https://tracker.debian.org/pkg/gcc-9

Which one version gcc 9 you've been using?
May I see gcc -v ?

@gniibe already wrote: “With gcc-9 in Debian experimental, everything goes well.”

BTW: fedora corp provides already free access to build envs with gcc 9 which can be easily integrated with CIs.

What you mean " it is not reproducible for u"?
Did you try to use gcc 9 and you had no problems compiling gnupg or you don't have access to build env with gcc 9?
Try to google to "gcc 9 pragma" and you will find several discussions and patches done by people fixing similar issues.

@kloczek , it is not reproducible for us, so, we consider it may be a problem other than GnuPG itself, possibly, some specific build configuration parameter(s) for GCC, or something by unreleased code.
Please file a report with how to reproduce your problem.

Why do you think that it is gcc bug?

So this seems to be a gcc bug, right. Then we should close this bug.