Bug or other problem with the toolchain (compiler, etc)
Mon, Feb 22
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).
Sun, Feb 21
Mon, Feb 15
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.
Sun, Feb 14
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 seem to apply to the other items already on the list. For instance texinfo, 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.
Fri, Feb 12
Feb 1 2021
no, that doesn't change anything.
Jan 31 2021
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 ...
Jan 30 2021
Compiling now works, but I get the following linker errors:
Jan 29 2021
Jan 28 2021
Jan 27 2021
Jan 24 2021
Does attached patch help?
Jan 23 2021
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:
Jan 5 2021
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