[PATCH] libgcrypt: Revert to inheriting from binconfig

[PATCH] libgcrypt: Revert to inheriting from binconfig

[Mike Crowe]

Commit 5870bd272b0b077d0826fb900b251884c1c05061 introduced
binconfig-disabled and enabled it for libgcrypt. This intentionally broke
the old-style libgcrypt-config binary since packages should be using the
pkg-config instead.

oe-core patches libgcrypt itself in order to generate a .pc file. This
patch was not accepted upstream because they do not wish to depend on
pkg-config. This means that upstream libgcrypt continues to ship with an
autoconf snippet that expects the libgcrypt-config binary so the configure
scripts shipped with other upstream projects (e.g. libmicrohttpd) also
expect to be able to find the libgcrypt-config binary.

If libgcrypt upstream doesn't generate a .pc file by default, then we
shouldn't expect other upstreams to make use of one. So, I think it makes
most sense to go back to installing a working libgcrypt-config binary until
that situation changes.

Signed-off-by: Mike Crowe <mac@mcrowe.com>
---
 meta/recipes-support/libgcrypt/libgcrypt.inc | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/meta/recipes-support/libgcrypt/libgcrypt.inc b/meta/recipes-support/libgcrypt/libgcrypt.inc
index 84c1cc018b..569e102c01 100644
--- a/meta/recipes-support/libgcrypt/libgcrypt.inc
+++ b/meta/recipes-support/libgcrypt/libgcrypt.inc
@@ -22,9 +22,7 @@ SRC_URI = "${GNUPG_MIRROR}/libgcrypt/libgcrypt-${PV}.tar.gz \
            file://fix-undefined-reference-to-pthread.patch \
 "
 
-BINCONFIG = "${bindir}/libgcrypt-config"
-
-inherit autotools texinfo binconfig-disabled pkgconfig
+inherit autotools texinfo binconfig pkgconfig
 
 EXTRA_OECONF = "--disable-asm"
 
-- 
2.11.0

Re: [PATCH] libgcrypt: Revert to inheriting from binconfig

[Burton, Ross]

[-- Attachment #1: Type: text/plain, Size: 472 bytes --]

On 24 May 2017 at 14:23, Mike Crowe <mac@mcrowe.com> wrote:

> If libgcrypt upstream doesn't generate a .pc file by default, then we
> shouldn't expect other upstreams to make use of one. So, I think it makes
> most sense to go back to installing a working libgcrypt-config binary until
> that situation changes.
>

The flip side of this being that we disabled the script because those sort
of scripts have terrible failure modes when cross-compiling...

Ross

[-- Attachment #2: Type: text/html, Size: 882 bytes --]

Re: [PATCH] libgcrypt: Revert to inheriting from binconfig

[Mike Crowe]

On Wednesday 24 May 2017 at 14:28:11 +0100, Burton, Ross wrote:
> On 24 May 2017 at 14:23, Mike Crowe <mac@mcrowe.com> wrote:
> 
> > If libgcrypt upstream doesn't generate a .pc file by default, then we
> > shouldn't expect other upstreams to make use of one. So, I think it makes
> > most sense to go back to installing a working libgcrypt-config binary until
> > that situation changes.
> >
> 
> The flip side of this being that we disabled the script because those sort
> of scripts have terrible failure modes when cross-compiling...

Oh, I thought that binconfig.bbclass swung through hoops in order to make
the scripts work well enough. Is that not true?

Many other recipes are still inheriting binconfig rather than
binconfig-disabled: apr, curl, gnutls, libtasn1.

Mike.

Re: [PATCH] libgcrypt: Revert to inheriting from binconfig

[Burton, Ross]

[-- Attachment #1: Type: text/plain, Size: 753 bytes --]

On 24 May 2017 at 14:52, Mike Crowe <mac@mcrowe.com> wrote:

> Oh, I thought that binconfig.bbclass swung through hoops in order to make
> the scripts work well enough. Is that not true?
>
> Many other recipes are still inheriting binconfig rather than
> binconfig-disabled: apr, curl, gnutls, libtasn1.
>

binconfig goes through hoops that are just not required with pkgconfig, and
the hoops are hacks which may not be reliable.  I can't remember the
details but I do remember that libgcrypt/gnupg was a worst offender here.

CCing Richard to see if he can remember why.

In the glorious future removing all binconfig scripts would be the ideal,
in my opinion.  Alternatively replacing them with glorified pkgconfig
wrappers.

Ross

[-- Attachment #2: Type: text/html, Size: 1285 bytes --]

Re: [PATCH] libgcrypt: Revert to inheriting from binconfig

[Richard Purdie]

On Wed, 2017-05-24 at 17:25 +0100, Burton, Ross wrote:
> 
> On 24 May 2017 at 14:52, Mike Crowe <mac@mcrowe.com> wrote:
> > Oh, I thought that binconfig.bbclass swung through hoops in order
> > to make
> > the scripts work well enough. Is that not true?
> > 
> > Many other recipes are still inheriting binconfig rather than
> > binconfig-disabled: apr, curl, gnutls, libtasn1.
> > 
> binconfig goes through hoops that are just not required with
> pkgconfig, and the hoops are hacks which may not be reliable.  I
> can't remember the details but I do remember that libgcrypt/gnupg was
> a worst offender here.
> 
> CCing Richard to see if he can remember why.
> 
> In the glorious future removing all binconfig scripts would be the
> ideal, in my opinion.  Alternatively replacing them with glorified
> pkgconfig wrappers.

We made a choice back then to go ahead and migrate these pieces to pkg-
config regardless of upstream's views since its so much cleaner and
less error prone than -config shell scripts which need hacking. We do
also patch the autoconf macros those pieces of software ship so that
pkg-config is used by the standard macros which covers most users
(since we reautoconf software).

Yes, binconfig.bbclass does have code which goes through hoops but I
don't think anyone would argue that code is pleasant or even scalable.
You can't easily change any of the sed expressions since you can't
easily know what set of file content they operate on and what side
effects any given change might have. The upstreams do change the
contents of the files over time and we can't really know if any given
replacements are still needed or if a new replacement may break other
files. Its also bad in that the on target versions need to differ to
the version used during cross building so you can't even have one
version of the file. I've seen these problems happen, my patches in the
past were after being burnt by that code.

For those reasons I believe we should be removing usage of
binconfig.bbclass from the system where we can if at all possible and
replacing it, even if it increases our custom patch load a little. I
know its used in a few places and I never did completely get rid of all
the config files but I still believe doing so would in fact be a
worthwhile effort.

I appreciate that does cause some pain as we're doing something
differently but I also believe it is justified. I would suggest
reminding these upstreams who won't at least allow pkg-config in
parallel that this does cause pain in the hope that if multiple people
report it, they may rethink things.

Cheers,

Richard

Re: [PATCH] libgcrypt: Revert to inheriting from binconfig

[Mike Crowe]

On Wednesday 24 May 2017 at 23:44:49 +0100, Richard Purdie wrote:
> On Wed, 2017-05-24 at 17:25 +0100, Burton, Ross wrote:
> > 
> > On 24 May 2017 at 14:52, Mike Crowe <mac@mcrowe.com> wrote:
> > > Oh, I thought that binconfig.bbclass swung through hoops in order
> > > to make
> > > the scripts work well enough. Is that not true?
> > > 
> > > Many other recipes are still inheriting binconfig rather than
> > > binconfig-disabled: apr, curl, gnutls, libtasn1.
> > > 
> > binconfig goes through hoops that are just not required with
> > pkgconfig, and the hoops are hacks which may not be reliable.  I
> > can't remember the details but I do remember that libgcrypt/gnupg was
> > a worst offender here.
> > 
> > CCing Richard to see if he can remember why.
> > 
> > In the glorious future removing all binconfig scripts would be the
> > ideal, in my opinion.  Alternatively replacing them with glorified
> > pkgconfig wrappers.
> 
> We made a choice back then to go ahead and migrate these pieces to pkg-
> config regardless of upstream's views since its so much cleaner and
> less error prone than -config shell scripts which need hacking. We do
> also patch the autoconf macros those pieces of software ship so that
> pkg-config is used by the standard macros which covers most users
> (since we reautoconf software).

[snip]

> I appreciate that does cause some pain as we're doing something
> differently but I also believe it is justified. I would suggest
> reminding these upstreams who won't at least allow pkg-config in
> parallel that this does cause pain in the hope that if multiple people
> report it, they may rethink things.

I was unaware that oe-core's libgcrypt recipe provides a modified
libgcrypt.m4 in share/aclocal/ that uses pkg-config.

Inspired by the oe-core gnupg recipe, I deleted m4/libgcrypt.m4 from the
libmicrohttpd source directory in a do_configure_prepend and everything now
seems happy.

Thanks, and sorry for the unnecessary diversion.

Mike.