Bug or other problem with the toolchain (compiler, etc)
Sun, Jan 24
Does attached patch help?
Sat, Jan 23
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:
Tue, Jan 5
Dec 26 2020
Dec 4 2020
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.
Dec 3 2020
Dec 1 2020
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:
Nov 30 2020
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.
Nov 29 2020
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.
Oct 3 2020
Aug 17 2020
No, c99 was never required. Meanwhile we use a few c99 features but those are supported without any compiler option.
Aug 14 2020
-std=c99 is probably the reason that the tests fail.
Please try with out supplied CFLAGS or change them from
Jul 16 2020
No info received
Jun 28 2020
Mar 20 2020
Mar 18 2020
Feb 17 2020
Yeah, this can be done.
Feb 10 2020
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.
Feb 6 2020
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.
Feb 3 2020
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.
Jan 29 2020
Apr 8 2019
For what I use, please refer: https://tracker.debian.org/pkg/gcc-9
Apr 7 2019
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.”
Apr 6 2019
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.