Let the compiler remove it. I added this comment:

Hmm - I can't explain why this would have affected 1.4.4 but not 1.4.3, but that
is my experience.

In general we try to avoid direct tests for OS features but use configure tests.
However in this case it is simpler to always include sys/time.h. This is
harmless because gcrypt.h does it also unconditionally.

I don't think that it is a regression in Libgcrypt because the problematic rule
was not changed. Did you change the CFLAGS passed to configure?

On further inspection I figured that it is not a unaligned problem, which would
clearly be a bug, but a restriction that the function works only onh full
blocks. This is the same as with CBC mode with the little difference that the
CBC mode detects this and returns an error. The most straightforward fix would
be to detect this usage error in CTR mode too.

Fixed in revision 1373. I don't think that this needs an extra test becaise the
error was sooooo obvious.

Okay, I can duplicate on a powerpc64.

Fixed. The new hmac256 problem has been split out to T979.

Duplicate of T979

my$ printf "what do ya want for nothing?" | ./hmac256 Jefe
hmac256: fatal error: self-test failed
my$

The second implementaion hmac code is also used by the hmac256 utiliy we install
since some time. Can you please run this and compare the result? (best with the
hmac256 in libgcrypt/src/):

Sometimes weird things happen :_(.

Out of curiosity, I tried to rebuild the 1350 revision that you linked to below,
and it also worked. I'm not sure what happened, but at least I cannot reproduce
this any more.

I've re-run the 'basic' self test several time, and it works every time (except
for the hmac problem).

I'm relatively certain that it is correct. I created by running 'make dist' on
my machine and transferring the entire libgcrypt-*.tar.gz archive to the Solaris
system and building libgpg-error and the libgcrypt archive there. The system
doesn't have libgpg-error or libgcrypt installed before. The only way I see
them being wrong would be if there is a gdb/gcc problem, which isn't completely
unlikely, the tools on that platform are fairly old (gcc 3.4.4).

Are you sure that the backtrace is really from svn1350? The given line numbers
don't match.

Another fix was needed, please use revision 1365.

Fixed in svn revision 1364. Will go into 1.4.4. If you want to test it, grab
http://cvs.gnupg.org/cgi-bin/viewcvs.cgi/*checkout*/trunk/mpi/mpi-pow.c?rev=1364&root=Libgcrypt

As found out after having filed this bug, it's the libtool devs who have failed
it: http://osdir.com/ml/gnu.libtool.bugs/2005-05/msg00249.html .. so now I at
least know I don't have to bother the people behind the projects that use
libtool with it.

This looks pretty much like an autoconf bug. However, a broken instalaltion of
a compiler is a bad sign for a system, so one might even be thabnkful for such a
message ;-).

You are wrong. My system operates correctly. Think chroot() (so no /dev) +
ligcrypt then. But if it was discussed then EOT.

No they are not. Your system is not operating correctly and thus there is no
other way than to terminate the process immediately. Most applications do not
bother to check return codes and thus Libgcrypt even does not provide a return
code for important operations like getrandom. The application can't resolve
that problem anyway.

It doesn't seem to work:

is the latest snapshot. I'd appreciate if you can test it so that I can close
this bug.

Thanks. I fixed that and described what the handler is expected to do.

If you make a release candidate I can test it on a solaris machine.

Next time I do code staring I should put off my Joo Janta 200 Super-Chromatic
Bug Sensitive Sunglasses first.

I did some more code staring and comparing to 1.2.x without a result.
I have still no Solaris box available but the Debian build logs of 1.4.1 show
that the tests all run fine.

Fixed in 1.4.1.

That is a gnutls problem.

I do not understand what is going on. rshift does not look different than add1.
Weird. Comparing with the non-asm versions might give further insight.

Here are the nm's .

If some extra output from libgcrypt-config is helpful for you, just let me know
and it will be added. But please use the mailing list for such a discussion.

We have never used pkg-config. That there has never been a build dependecy on it.

D54: 165_libgcrypt-mpi-symbol-alpha.diff

Ah well, this is an alpha. As a quick workaround you can use

--disable-padlock disables the asm code and thus you should not get the same
compile error. Please check that there is no

Assuming you're talking about an extra dependency for building gcrypt, it would
be easy to build and install the *.pc without using the autoconf macros that
come with pkg-config. That said, everyone has pkg-config these days--apparently
gcrypt had a build-dependency on it and nobody even noticed (IIRC it was being
build, just not installed)? That's a decent indicator that nobody would mind, IMHO.

It was accidently left in the SVN. I remove it.

D55: 164_gcrypt-pkgconfig.diff