Thank you for further information.
Now, I understand your situation of mixture of architectures.
I think that your source code was once configured by 32-bit environment (which
created links to 32-bit), and then you tried to configure and to compile by
64-bit environment which caused errors.

I think that "make distclean; configure; make" would success even on the 32-bit
environment with different host OS.

Apr 8 2015, 4:40 AM · Bug Report, libgcrypt

Apr 7 2015

naturalmessage added a comment to T1936: FreeBSD 10.1: mpi alignment error during compile.

libgcrypt compiles fine on regular FreeBSD 10.1 with the proper
architecture. The problem with the mismatched architecture was because
I was on a virtual machine and I had to run a 32 bit OS in the machine
because my 64-bit hardware didn't have hardware virtualization and
would only run a 32-bit OS. I guess that situation isn't too common,
but I'll leave it to you to classify the original report as a bug or
converted feature request/idea.

Apr 7 2015, 6:12 PM · Bug Report, libgcrypt

Apr 3 2015

• gniibe added a comment to T1936: FreeBSD 10.1: mpi alignment error during compile.

It seems for me that your build environment is not clean and has some links for
i386, while your arch is x86_64. It is i386's mpih-add1 which has ALIGN(3) at
line number 44.

Please do 'make distclean' and configure, then make.

Apr 3 2015, 8:56 AM · Bug Report, libgcrypt

Mar 29 2015

naturalmessage added a comment to T1936: FreeBSD 10.1: mpi alignment error during compile.

594_asm-syntax.h2 KBDownload

Mar 29 2015, 8:29 PM · Bug Report, libgcrypt

naturalmessage added a comment to T1936: FreeBSD 10.1: mpi alignment error during compile.

596_sysdep.h77 BDownload

Mar 29 2015, 8:29 PM · Bug Report, libgcrypt

naturalmessage added a comment to T1936: FreeBSD 10.1: mpi alignment error during compile.

This is related to the "ALIGN (3)" mpi code that caused a compile
problem on FreeBSD 10.1 (I changed it to "ALIGN (2)" and it compiled,
but I'm not sure if that will break something).

Mar 29 2015, 8:29 PM · Bug Report, libgcrypt

naturalmessage added a comment to T1936: FreeBSD 10.1: mpi alignment error during compile.

593_naturalmessageLenovoN50hw.txt8 KBDownload

Mar 29 2015, 8:29 PM · Bug Report, libgcrypt

naturalmessage added a comment to T1936: FreeBSD 10.1: mpi alignment error during compile.

595_mod-source-info.h284 BDownload

Mar 29 2015, 8:29 PM · Bug Report, libgcrypt

• werner added a comment to T1936: FreeBSD 10.1: mpi alignment error during compile.

We did not changed anything in this code for many many years. This seems to be
a configure problem: The configure script (actually mpi/config.links) figured
that you are using BSD_SYNTAX but in reality as(1) requires ELF_SYNAX.

What is the cpu-os-vendor string? Look at mpi/asm-syntax.h in the build
directory - the top 3 lines shows this.

be an as(1) problem.

Mar 29 2015, 3:49 PM · Bug Report, libgcrypt

Mar 28 2015

naturalmessage added projects to T1936: FreeBSD 10.1: mpi alignment error during compile: libgcrypt, Bug Report.

Mar 28 2015, 7:24 AM · Bug Report, libgcrypt

Mar 11 2015

• werner added a comment to T1881: Undefined behavior when running `make check` under Clang sanitizers.

FWIW: libgpg-error.so.0: no version information available"
is a harmless diagnostic issued for example by Debian to help detecting broken
ABIs. It is a non-issue here. We can't do anthing about it. With some
libgpg-error we introduced symbol versioning to assist the loader and to hide
internal symbols from other ELF objects.

Mar 11 2015, 6:03 PM · Bug Report, libgcrypt

jukivili added a comment to T1881: Undefined behavior when running `make check` under Clang sanitizers.

Unaligned memory accesses are enabled on only architectures that can handle
those. The buf_xor function that you copy-pasted partially to stackoverflow
actually has alignment checks:

#if defined(i386) || defined(x86_64) || \

defined(__powerpc__) || defined(__powerpc64__) || \
(defined(__arm__) && defined(__ARM_FEATURE_UNALIGNED)) || \
defined(__aarch64__)

/* These architectures are able of unaligned memory accesses and can

  handle those fast.
*/

define BUFHELP_FAST_UNALIGNED_ACCESS 1 #endif ... /* Optimized function for buffer xoring */ static inline void buf_xor(void *_dst, const void *_src1, const void *_src2, size_t len) { byte *dst = _dst; const byte *src1 = _src1; const byte *src2 = _src2; uintptr_t *ldst; const uintptr_t *lsrc1, *lsrc2; #ifndef BUFHELP_FAST_UNALIGNED_ACCESS const unsigned int longmask = sizeof(uintptr_t) - 1; /* Skip fast processing if buffers are unaligned. */ if (((uintptr_t)dst | (uintptr_t)src1 | (uintptr_t)src2) & longmask) goto do_bytes; #endif ldst = (uintptr_t *)(void *)dst; lsrc1 = (const uintptr_t *)(const void *)src1; lsrc2 = (const uintptr_t *)(const void *)src2; for (; len >= sizeof(uintptr_t); len -= sizeof(uintptr_t)) *ldst++ = *lsrc1++ ^ *lsrc2++; dst = (byte *)ldst; src1 = (const byte *)lsrc1; src2 = (const byte *)lsrc2; #ifndef BUFHELP_FAST_UNALIGNED_ACCESS do_bytes: #endif /* Handle tail. */ for (; len; len--) *dst++ = *src1++ ^ *src2++; }

So, yes, we use unaligned memory accesses but only when it is known that they work.

Now, solution (with same code generation, without undefined behaviour) to this
issue is to tell the compiler that we really want to do unaligned accesses. For
that we need to change the accesses to happen through type that has proper
one-byte alignment, but generates the same code (unaligned word-size memory
accesses) on the few architectures that enable 'BUFHELP_FAST_UNALIGNED_ACCESS':

#ifdef BUFHELP_FAST_UNALIGNED_ACCESS
/* Define type with one-byte alignment on architectures with fast unaligned

  memory accesses.
*/

typedef struct bufhelp_int_s
{

uintptr_t a;

} attribute((packed, aligned(1))) bufhelp_int_t;
#else
/* Define type with default alignment for other architectures (unaligned

  accessed handled in per byte loops).
*/

typedef struct bufhelp_int_s
{

uintptr_t a;

} bufhelp_int_t;
#endif

Ofcourse, BUFHELP_FAST_UNALIGNED_ACCESS now need to be limited to compiler that
support GCC style attributes.

Mar 11 2015, 6:00 PM · Bug Report, libgcrypt

jukivili claimed T1881: Undefined behavior when running `make check` under Clang sanitizers.

Mar 11 2015, 5:35 PM · Bug Report, libgcrypt

Mar 10 2015

• werner added a comment to T1863: libgcrypt offers/uses --with-pth-prefix.

That is used for an experimental tool of Libgcrypt (src/gcryptrnd). It is not
clear whether this will be ported to npth or removed.

Mar 10 2015, 5:06 PM · libgcrypt

• werner added a comment to T1919: Libgcrypt in Gpg4Win has AES-NI support disabled.

Since then we did a lot of work on Libgcrypt so that the AES-NI code is
different from May 2012. It is possible that we accidently clobbered a register
which might have been the reason for the VirtualBox failure.

I can't remember the test case, but any use of AES should have hit it. Just use
gpg where AES is the default anyway. I suggest to revert that patch an see what
happens.

Mar 10 2015, 10:56 AM · libgcrypt, Feature Request, gpg4win

• werner added a comment to T1894: mpi-bit: numerous potential null pointer dereferences.

BTW: Anyone using -DNDEBUG should be punished by having to read BIND 4 code for
the next 3 months.

Mar 10 2015, 10:10 AM · Mistaken, libgcrypt

• werner added a comment to T1894: mpi-bit: numerous potential null pointer dereferences.

No c+p of warnings please! Use gnupg-devel for such things.

Mar 10 2015, 10:08 AM · Mistaken, libgcrypt

• werner added a project to T1894: mpi-bit: numerous potential null pointer dereferences: Mistaken.

Mar 10 2015, 10:08 AM · Mistaken, libgcrypt

• werner added a comment to T1899: primegen.c: uses is_locked, which appears to suffer a race.

Sure it used and thus read! You only need to look at the code for 5 seconds!
And no, it is not a lock. Read the comment at the var definition.

Mar 10 2015, 10:07 AM · Not A Bug, libgcrypt