User Details
- User Since
- Mar 27 2017, 4:48 PM (205 w, 2 d)
- Availability
- Available
Aug 15 2020
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.
Aug 14 2020
-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
Aug 10 2020
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.
Aug 5 2020
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.
Aug 2 2020
Apr 6 2020
I'd be interested in seeing the results of testing the patch. Can you provide a link to the results?
Apr 3 2020
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:
Apr 2 2020
There is nothing spiteful about this other than your actions.
werner closed this task as Spite.
We do not use Github.
Apr 1 2020
Also see Issue #10, Add Travis testing in the GnuPG GitHub. The PR adds Travis testing to the entire GnuPG suite.
Jan 29 2020
May 14 2019
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.
May 13 2019
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.
May 12 2019
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.
May 11 2019
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.
May 10 2019
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.
Mar 8 2019
Similar issue with ntbtls:
Mar 7 2019
Libassuan 2.5.3 has a similar problem:
Dec 30 2018
Dec 29 2018
Here's the patch:
Jul 21 2015
Werner Koch <wk@gnupg.org> added the comment:
Please show me the disassembly of an example along with the commands and program
versions you used to create an object file with removed wipememory code.
Jul 16 2015
Jul 6 2015
volatile is used to make sure the writes actually hit the
memory. gcc is not allowed to remove that for the simple reason, it
can't know whether this plain RAM or a device mapped into the address
space. That is the whole point of using volatile and it has been
introduced back in the 80ies for just this reason (back than to write
to video memory).
Jun 17 2015
One relatively unimportant misunderstanding is due to the fact that
the standard only talks about accesses to volatile objects. It does
not talk about accesses via volatile qualified pointers. Some
programmers believe that using a pointer-to-volatile should be
handled as though it pointed to a volatile object. That is not
guaranteed by the standard and is therefore not portable. However,
this is relatively unimportant because gcc does in fact treat a
pointer-to-volatile as though it pointed to a volatile object.It says that it's not guaranteed and it's not portable by the C
language itself.So, you are right that volatile qualifier to a pointer should be
avoided (from viewpoint of portability).I think that I am also right that it works with GCC implementation
(in 2008, at least).
I'm actually more concerned that the optimizer will remove the code
because it surmises its a dead store. That's the issue I am trying to
articulate.
You shouldn't use volatile for that when compiling with GCC.
Any references which support this opinion of yours, please?
On Tue, Jun 16, 2015 at 4:31 AM, NIIBE Yutaka via BTS
<gnupg@bugs.g10code.com> wrote:
NIIBE Yutaka <gniibe@fsij.org> added the comment:
I think that JW had some confusion. I believe that his argument is irrelevant
for libgcrypt's implementation of wipememory.
Mar 6 2015
Changed status to 'unread'. I'm not chatting.
I was able to duplicate Bug 1862: Building static GnuPG 2.1.2 fails due to
multiply defined symbols.
/home/jwalton/Desktop/gcrypt-2.0-analyze/libgpg-error-1.18/src/visibility.c:46:
multiple definition of `gpg_err_code_from_errno'
t-support.o:/home/jwalton/Desktop/gcrypt-2.0-analyze/gnupg-2.1.2/common/t-support.c:137:
first defined here
/home/jwalton/gpg-analyze/lib/libgpg-error.a(libgpg_error_la-visibility.o): In
function `gpg_err_code_from_syserror':
/home/jwalton/Desktop/gcrypt-2.0-analyze/libgpg-error-1.18/src/visibility.c:58:
multiple definition of `gpg_err_code_from_syserror'
t-support.o:/home/jwalton/Desktop/gcrypt-2.0-analyze/gnupg-2.1.2/common/t-support.c:151:
first defined here
collect2: error: ld returned 1 exit status
make[3]: * [t-stringhelp] Error 1
make[3]: Leaving directory
`/home/jwalton/Desktop/gcrypt-2.0-analyze/gnupg-2.1.2/common'
make[2]: * [all] Error 2
make[2]: Leaving directory
`/home/jwalton/Desktop/gcrypt-2.0-analyze/gnupg-2.1.2/common'
make[1]: * [all-recursive] Error 1
make[1]: Leaving directory `/home/jwalton/Desktop/gcrypt-2.0-analyze/gnupg-2.1.2'
make: * [all] Error 2
LIBRARY=gnupg
VERSION=2.1.2
FILE="$LIBRARY-$VERSION"
export PREFIX=/usr/local
cd "$FILE"
./configure --enable-static --disable-shared
--with-libgpg-error-prefix="$PREFIX" --with-libassuan-prefix="$PREFIX"
--with-ksba-prefix="$PREFIX" --with-npth-prefix="$PREFIX"
--with-libgcrypt-prefix="$PREFIX" --prefix="$PREFIX"
make