This patch should work if configure properly detects need for extra underscore on C symbols:

Sorry to dig up an old report...

Sorry to dig up an old thread...

Here's the patch I am using for the Apple M1: libgcrypt-darwin.patch. The patch is public domain so anyone is free to use it.

This is kind of a hack, but this patch:

Here's the patch:

I believe the problem here is OS X 10.12's (and above) System Integrity Protection (SIP). SIP protects system integrity by doing things like sanitizing environmental variables for system programs. Sanitizing environmental variables on system programs avoids code injections.

-std=c99 is probably the reason that the tests fail.

I understand your point, but your fix is not relevant

I'm feeling difficulty to talk to you.

... no-support of slash at the end of path and duplicated slash, we won't fix.

T5024: libtool problem for some platforms for 'make check' (program built with -no-install won't work without installation)

I wrote that "FAIL: gpg-error-config-test.sh" is because of your typo

... you are now describing another problem

The problem appears to be the test framework is not setting a LD_LIBRARY_PATH (or DYNLD_LIBRARY_PATH on OS X).

As far as I know, the environment is set correctly. PKG_CONFIG_PATH, --prefix and --libdir are set. And runpaths are also set.

If you can point me to a commit, I can patch the package and retest it.

According to OS X 10.9 man pages for getenv(3) (10.9 is what I have available), the source file editinteractor.cpp should include <stdlib.h>. Since its a c++ source file, I believe the include of interest is <cstdlib>. The man page also says the link library is -lc.

I'd be interested in seeing the results of testing the patch. Can you provide a link to the results?

You can test with newer compiler.

It looks like the recipe to build the source file is missing the necessary arch options. I.e., -mcpu=power7 -mvsx ...

I can't reproduce the error (no problem for build). My (cross-)compiler is:

There is nothing spiteful about this other than your actions.

werner closed this task as Spite.

We do not use Github.

Also see Issue #10, Add Travis testing in the GnuPG GitHub. The PR adds Travis testing to the entire GnuPG suite.

In case of gcc 4.8 on Solaris, could you please try this patch (instead of configure patch) to see if it works?

rG5b22d2c4008 tested good under Asan.

I was talking to Thomas Dickey, who maintains Ncurses. Ncurses had a leak and he offered a config option to remove it. Ncurses config responds to --disable-leaks.

Dynamic loading of Libgcrypt is anyway not supported; those who do that are on their own.

I'm going to bring newest m4/iconv.m4 from original (gettext), which apparently fixed file descriptor leaks.

An FYI... Once we cleared the earlier findings GnuPG tested OK under Asan. GnuPG itself had no findings, and it did not cause any dependent libraries to generate findings.

This patch tested OK.

The second and third arguments passed to xgcry_control seem to be lost when calling gcry_control.

Here are the next two failures I am seeing while testing libgrcypt. It appears to be related to GCRYCTL_INIT_SECMEM.

I'm still seeing a few odd outputs from make check, but I have not investigated them yet.

Maybe cleaner option for mpi/mpiutil.c would be to statically allocate the constants

Here's a couple of awful hacks that get me through make check. Feel free to restate how awful they are; I know it is a bad thing to do.

It looks like this patch clears this finding:

It looks like this patch clears this finding:

It looks like Solaris only needs CFLAGS+=-std=c99. It was added for all programs and libraries listed at https://www.gnupg.org/download/index.html.

Similar issue with ntbtls:

Libassuan 2.5.3 has a similar problem: