libgcrypt build failures on several platforms
Closed, ResolvedPublic


After installing libgpg-error-1.36, the installation of libgcrypt-1.8.5 fails on

Additionally, although the build succeeded, there are test failures on:

bhaible created this task.Jan 20 2020, 1:27 AM
gniibe added a subscriber: gniibe.Jan 20 2020, 5:24 AM

Please give us log for Solaris 11 Openindiana.

Here are the logs. The package was configured with
CC="gcc -m64 -O2 -D_XOPEN_SOURCE=700"

gniibe claimed this task.Jan 20 2020, 11:02 AM

Thanks. I see the situation for Solaris 11 Openindiana. In master (will be 1.9.0), it has no problem.
We need to fix in 1.8. I will.

werner triaged this task as Normal priority.Jan 20 2020, 3:37 PM
werner added projects: libgcrypt, Solaris.

In solaris11openindiana-log2, we have two errors: one for ulong, and another for ushort.
I fixed the former. It is because of our mistake of using ulong before it is handled by libgcrypt/src/types.h. In the first place, it is implemented by "unsigned long", so, there is no need to use ulong here.

I don't see the reason why the latter error occurs.
IIUC, on Solaris, ulong/ushort/etc. are defined in <sys/types.h>. And those are detected in solaris11openindiana-log1 correctly.
By defining __EXTENSIONS__ in config.h for Solaris, the type definition of ushort should be available: g10lib.h in libgcrypt/src -> types.h in libgcrypt/src -> <sys/types.h>

If any information about the definition of ushort on Solaris 11 Openindiana, please let me know.

For GNU/Linux or GNU/kFreeBSD system, libgcrypt 1.8 with libgpg-error 1.36 has no problem in Debian build:

Let me see what's going on...

OK, I identified the problem on OpenIndiana. The inclusion of <unistd.h> causes inclusion of <sys/types.h> before config.h. I'm going to fix this.

On Solaris, the test errors are because of:

       Because of the impact on system resources, the use of mlock() and
       munlock() is restricted to users with the {PRIV_PROC_LOCK_MEMORY}

When I run t-secmem and t-sexp by root, it works.

I tested on FreeBSD. Same errors (t-secmen and t-sexp) are reproducible when we set:

# sysctl security.bsd.unprivileged_mlock=0

(while the default is 1).

I think that setting 1 to the kernel parameter on GNU/kFreeBSD, it will work.

For Cygwin, I can't find how its libgcrypt package is built.
I found this for MSYS2:
This for Mingw-w64:

It looks like MSYS2 packaging is from Fedora Project???

Regarding GNU/kFreeBSD, my machine is using the FreeBSD 9.0 kernel, which does not yet have the security.bsd.unprivileged_mlock oid. Like what was mentioned here:

werner closed this task as Resolved.