Thanks very much! I have solved the problem.

Please do not post files in closed formats like Microsoft word. We will only
look at reports in a plain text format.

From your description it looks more like a build problem because Libgcrypt is
already part of Ubuntu and installing a different version is possible but you
need to get some things right. In general I would suggest to write to
gcrypt-devel@gnupg.org

Yes, it's the same issue.

Isn't this the same as T2975 ?

Yes, .cpu generic+simd+crypto that what I thought after first patch from the beginning
but didn't test it first, blame me for it. Now it compiles as expected, please include
it into next release.

D410: 957_03-fix-clang-arm64.patch

How about this patch?

No, it still fails, here is fresh log:
http://pkg.krion.cc/data/110arm64-default/2017-02-26_16h58m38s/logs/errors/libgcrypt-
1.7.6.log

Does the attached patch fix the problem?

D411: 956_02-fix-clang-arm64.patch

Ok, thanks!

You need to wait for 1.8 - in a few weeks.
I looked at the required changes but decided not to backport that for 1.7.6.

I have now learnt how GCC uses 'undefined behavior' for aggressive optimization
and that this could break code doing unaligned accesses even on x86. So this
needs to be fixed after all.

There have been some problems backporting the batch to 1.7 thus it will not go
into 1.7.6.

The patch has been applied to master and the 1.7 branch. A 1.7.6 will be
released soon.

D402: 933_01-rijndael-ssse3-fix-compiling.patch

Attached patch should solve LTO problems with rinjdael-ssse-amd64.c.

'memcpy' problem seems to be because of bad interaction between -flto and
#pragma "no-sse". Strangely switching memcpy to buf_cpy solved problem, even
through buf_cpy itself just uses memcpy (on x86).

With this issue solved, I ran in to problem with rijndael-ssse3 assembly code
blocks going missing with -flto and link failing. So rest of the changes in
patch are for fixing lto visibility of assembly.

Yes, sure.

werner: Well... Doesn't it destroy libgcrypt's performance?

Jussi: would you be so kind and look at this problem?

The configure option --disable-asm might help.

Applied with commit 0a90f87799 to master. I will backport and release 1.7.5 today.

The Gentoo bug report for this has a
proposed fix, correcting a typo (EGAIN-

EAGAIN) in an autoconf script.

https://bugs.gentoo.org/show_bug.cgi?
id=602502#c5

I improved our test suite so that it detects this problem.

This is indeed a bug in libgcrypt. Thanks for the report.

No info recevied and thus closing. You should switch to 1.7 (and soon 1.8)
anyway. A lot of things have been fixed since 1.6.

FWIW, we do not see any problem with current Libgcrypt in our CUI system running
under Sierra.

Given that the patent expired I consider touching that comment not important.

Sorry for not providing further infos, I did not find the time before now.
I just tested with version 1.7.2; there the problem has disappeared.

I guess this change mentioned in the change log is the relevant one:
+2016-07-01 Jussi Kivilinna <jussi.kivilinna@iki.fi>
+
+ Fix static build.
+ * tests/pubkey.c (_gcry_pk_util_get_nbits): Make function 'static'.

Thank you very much, the case can be closed.

I confirmed on AIX 7.1 with GCC 4.8.1, libgcrypt 1.7.2 builds well. "make
check" goes success with no errors.
I'm closing this again, because the particular problem of typedef has been fixed.
If you have another issue, please open another report.

I see. We use system() in the random test to re-execute itself. This involves
the shell and thus the problem. Need to uses fork/exec or CreateProcess calls
for that test. I guess this needs to wait until we have moved that to code to
libgpg-error as our portability layer.

This is still a problem on OS X 10.11.5. OS X's System Integrity Protection
"feature" is causing that test failure. If S.I.P is disabled there's no problem.

A similar-looking test failure happens in perl
(https://rt.perl.org/Public/Bug/Display.html?id=126706). Perhaps the diagnosis is
the same here.

You may want to test 1.7.2 instead.

1.7.2 with the fix has been released

commit 3f98b1e adds a better fatal error message. Will be released with 1.7.2.

It has been fixed with commit 4a983e3.

Currently, there is no need for alignmask API. Implementations that we have at
the moment can handle unaligned data and some have fast paths for word-aligned
in/out buffers (which malloc can provide).

We could add section in documentation about appropiate memory alignment for best
performance, and tell to align buffers to cacheline size.

Hello,

I posted fix for this issue to mailing-list. See:
http://marc.info/?l=gcrypt-devel&m=146732375910584&w=2

Hi,

Can you please let me know if we could get hold of the older version than
1.7.1 of libgcrypt ?

Can you please let me know how we can fix this bug. We are using Redhat Linux 6
and the highest version it supports for gcc is 4.4.x . If we need to go for a
higher version we need to download source code and do the rpm( which may take
more time. )

It seems that it's the bug of libgcrypt.
https://lists.gnupg.org/pipermail/gcrypt-devel/2016-June/003901.html

Well it is a bug in your code and not in Libgcrypt. The md_read function is
guaranteed to always return a valid digest. However if you explicitly for SHA1
and SHA1 is not enabeld in the context we can't continue. Better use 0 as
second arg to md_read.

I will improve the error message for 1.7.2

I think that it requires GCC version 4.6 or later for AVX instruction.
4.9 or later is better.
Ideally, configure should check GCC version.

Awesome, that did the trick!
Many thanks.

Sorry, my near sight. I only fixed cofactor support, in a case where "h" is
provided.
I should have fixed other parts, too. Now, I fixed in master:

http://git.gnupg.org/cgi-bin/gitweb.cgi?p=libgcrypt.git;a=commitdiff;h=0f3a069211d8d24a61aa0dc2cc6c4ef04cc4fab7;hp=fa917d2e24b0c98143a079ab4889ad8f69bee446

It is backported to 1.7 branch too.

libaacs should work with this patch.