Thanks for report. I've applied this change to master.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
May 8 2024
May 7 2024
Aug 25 2021
Apr 26 2021
Feb 12 2021
Feb 6 2021
Problem with clang and these files was resolved by replacement of assembler macros with C preprocessor macros.
Jan 29 2021
Jan 28 2021
Jan 23 2021
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.
Jan 22 2021
Should we add this to the hints in the README? After all this does not seem to be the standard system compiler or it has not been properly setup as replacement.
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
In T5255#141976, @jukivili wrote:Unfortunately these are not enough to enable building with clang LTO. Build now fails when linking test executables (libgcrypt.so gets build however):
Any ideas what might be causing this?
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
Breakage appears to happen in configure.ac. When building with clang without LTO following check gives "no":
Both are affected. I updated to reflect that I tested the newer version
Nov 28 2019
Apr 1 2019
I think commit https://git.gnupg.org/cgi-bin/gitweb.cgi?p=libgcrypt.git;a=commit;h=09c27280cc09798d15369b3a143036b7ab5ddd69 should be backported to 1.8 branch of libgcrypt.
Mar 25 2019
Thank you, it worked.
Mar 24 2019
Jan 10 2019
Set to high because it breaks a build.
Aug 15 2017
It's been a month since last release, no error reports so far.
Jul 4 2017
Should be fixed in 782f804765b6f4226fd77843e59f57dcca61b6fb, can you verify that? Thanks!
Jun 7 2017
Marcus, can you please check this?