- User Since
- Mar 27 2017, 4:48 PM (215 w, 2 d)
Wed, Apr 28
Mon, Apr 26
Apr 12 2021
Apr 6 2021
Note that rndjent.c is already build with -O0 as can be seen in example above. That warning could be silenced by surrounding pragma with #ifdef __OPTIMIZE__ (with should be supported by GCC and Clang).
Apr 1 2021
Mar 30 2021
@werner Can you comment about bugfix release?
These functions are internal to library and, for example, on linux/windows builds are not externally available.
Mar 29 2021
This patch should work if configure properly detects need for extra underscore on C symbols:
Mar 26 2021
Mar 25 2021
Thanks for the report.
Mar 12 2021
Mar 9 2021
Pushed to master with two commits:
Mar 7 2021
I posted patch-set to mailing-list. Please check if AUTHORS/LICENSES updates are ok.
I've cleaned up the patch from D501 and tweaked the implementation a bit for performance. Here's patches attached:
Mar 6 2021
Fixed typos and applied to master. Thanks.
Mar 3 2021
Feb 12 2021
Feb 6 2021
Problem with clang and these files was resolved by replacement of assembler macros with C preprocessor macros.
Feb 4 2021
The 'what != NULL' case is handled by the "Strip trailing LF" part at the end of function. These data strings always end with '\n', so null-termination gets done there.
Feb 3 2021
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 29 2021
Thanks for your report.
Jan 28 2021
Patch for this bug is available here, "attachment-0001.bin": https://lists.gnupg.org/pipermail/gcrypt-devel/2021-January/005079.html
I tested xenial with gcc-5.3 (xenial distro repo) and gcc-5.4 (xenial-updates distro repo) and libgcrypt 1.9.0 from git repo and from tarball. I did not get any errors.
Jan 27 2021
Jan 26 2021
I tested building on Ubuntu 8.04 (gcc-4.2) and got same error about cipher_bulk_ops_t. Applying patch fixed that problem.
Thanks for testing. However, I do not believe patch has been correctly applied.
Jan 25 2021
Here's patch to try out:
In "src/cipher-proto.h", try removing typedef and leaving just forward declaration of structure.
Jan 24 2021
Does attached patch help?
Jan 23 2021
Thanks for the report. As you noticed, issue had been reported already.
That might be helpful. But, on the other hand, if I had just googled the problem I was seeing I would have gotten answer quite fast.
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
Jan 22 2021
Problem was that my build system was selecting "ar" and "ranlib", where as your build system selects "llvm-ar" and "llvm-ranlib".
Jan 21 2021
Configure output has still has some differences LTO vs non-LTO:
--- non-lto.log 2021-01-21 22:25:14.966099577 +0200 +++ lto.log 2021-01-21 22:25:23.174086100 +0200 @@ -63,7 +63,7 @@ checking for archiver @FILE support... @ checking for strip... strip checking for ranlib... ranlib -checking command to parse /usr/bin/nm -B output from clang object... ok +checking command to parse /usr/bin/nm -B output from clang object... failed checking for sysroot... no checking for mt... mt checking if mt is a manifest tool... no @@ -75,7 +75,7 @@ checking if clang static flag -static works... yes checking if clang supports -c -o file.o... yes checking if clang supports -c -o file.o... (cached) yes -checking whether the clang linker (/usr/bin/ld -m elf_x86_64) supports shared libraries... yes +checking whether the clang linker (/usr/bin/ld) supports shared libraries... yes checking whether -lc should be explicitly linked in... no checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate @@ -168,8 +168,8 @@ checking whether 'asm' assembler keyword is supported... yes checking whether '__asm__' assembler keyword is supported... yes checking whether inline assembly memory barrier is supported... yes -checking whether GCC assembler is compatible for ARM assembly implementations... no -checking whether GCC assembler is compatible for ARMv8/Aarch64 assembly implementations... no +checking whether GCC assembler is compatible for ARM assembly implementations... yes +checking whether GCC assembler is compatible for ARMv8/Aarch64 assembly implementations... yes checking whether GCC assembler supports for CFI directives... yes checking whether GCC assembler supports for ELF directives... yes checking for _ prefix in compiled symbols... no @@ -240,7 +240,7 @@ checking if gcc supports -Wno-missing-field-initializers... yes checking if gcc supports -Wpointer-arith... yes checking whether non excutable stack support is requested... yes -checking whether assembler supports --noexecstack option... yes +checking whether assembler supports --noexecstack option... no checking that generated files are newer than configure... done configure: creating ./config.status config.status: creating Makefile
Clang support Intel syntax after all, but not assembler macros that were used. Here's two patches that fix the configure.ac issue and removes use of assembly macros in Intel syntax assembly files:
Jan 20 2021
Merged to master.
Merged to master.
Merged to master.