gniibe at fsij.org
Fri Jul 13 07:22:15 CEST 2018
I'd like to adopt pkg-config methodology to GnuPG. I mean,
I know that we had discussions in the past.
Since then, situation has been changed; pkg-config 0.27 and later allow
--with-internal-glib option at configure time. We also have pkgconf
now. I think that our concern about dependency to another software is
So, I think that we can move now.
For GnuPG configure, we now have following:
Using those *-config works, but I think that using pkg-config is better.
At least, using pkg-config which supports multiple libraries at once,
linking can be simplified and accurate.
Today, I have a specific problem.
These days, libgpg-error is used by many (ksba, assuan, gcrypt, ntbtls,
and GnuPG itself). Now, using each *-config, GnuPG's linking has
It is only redundant, for normal case, that's true.
But for a developer, who installs development version of libgpg-error in
/usr/local (and still keep using old libgpg-erro in system), he may
encounter a problem, say, if he still uses old ksba package.
That's because... while ksba-config --libs returns (for example)
-L/usr/lib/x86_64-linux-gnu -lksba -lgpg-error
new gpg-error-config --libs returns
Then, appending those to generate the executable kbxutil in gnugp/kbx,
old libgpg-error is selected, unfortunately.
I think that now is a good opportunity to move on.
More information about the Gnupg-devel