running configure --with-libgpg-error-prefix=prefix doesn't cause a command line
option of -I prefix/include for gcc. So building gpg uses the gpg-error.h in
/usr/include if available.
Workaround is to put CC="gcc -Iprefix/include" on the command line before the
configure.
(this is on a gentoo linux box)
That option gives the installation directory of libgpg-error which is in turn
used to run gpg-error-config to get the various build flags. Thus it depends
on how you installed libgpg-error. See also config.log to see what configure
figured out about libgpg-error.
I've attached the output of configure and make as well as config.log.
You can see that GPG_ERROR_CFLAGS is computed properly, it just doesn't
seem to propagate.
On Mon, Oct 28, 2013 at 9:25 AM, Werner Koch via BTS <gnupg@bugs.g10code.com
wrote:
Werner Koch <wk@gnupg.org> added the comment:
That option gives the installation directory of libgpg-error which is in
turn
used to run gpg-error-config to get the various build flags. Thus it
depends
on how you installed libgpg-error. See also config.log to see what
configure
figured out about libgpg-error.
status: unread -> chatting
g10 Code's BTS <gnupg@bugs.g10code.com>
<T1561>
I improved this by adding missing CFLAGS and re-ordering some.
But that this is not a complete solution. The libgpg-error include
directory has now a higher preference but ld may not pick up the right
library if another one is installed. The problem is that the -L
option and the -l options are not emitted separately by
gpg-error-config.