All of lore.kernel.org
 help / color / mirror / Atom feed
From: Allen Martin <amartin-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
To: Thomas Petazzoni
	<thomas.petazzoni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
Cc: Stephen Warren <swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>,
	linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [tegrarcm PATCH] Don't assume cryptopp is system-wide installed
Date: Thu, 21 Apr 2016 11:13:59 -0700	[thread overview]
Message-ID: <20160421181359.GA17433@nvidia.com> (raw)
In-Reply-To: <20160420112735.16eca48a-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>

On Wed, Apr 20, 2016 at 11:27:35AM +0200, Thomas Petazzoni wrote:
> On Tue, 19 Apr 2016 16:57:45 -0700, Allen Martin wrote:
> 
> > What about the following as an alternative?
> > 
> > --
> > diff --git a/src/Makefile.am b/src/Makefile.am
> > index 3dad0e6d5e72..22410b3f81bf 100644
> > --- a/src/Makefile.am
> > +++ b/src/Makefile.am
> > @@ -1,5 +1,6 @@
> >  AM_CFLAGS = -Wall -std=c99
> > -AM_CPPFLAGS = -isystem /usr/include/$(CRYPTOLIB) $(LIBUSB_CFLAGS)
> > +CRYPTO_PREFIX = $(shell pkg-config --variable=includedir libcrypto++)
> 
> Using pkg-config is indeed a much better option. However, there are
> several gotchas:
> 
>  - First, calling pkg-config like this is not the correct way of using
>    pkg-config in autoconf/automake based packages. Instead, you should
>    use the PKG_CHECK_MODULES() autoconf macro, which will fill in for
>    you the <foo>_CFLAGS and <foo>_LIBS variables. Look at your
>    configure.ac, it is already used for the detection of libusb!

Unfortunately, libcrypto++ doesn't export any CFLAGS, so
PKG_CHECK_MODULES() doesn't work:

  arm@chrome~$ pkg-config --cflags libcrypto++
 
  arm@chrome~$ pkg-config --libs libcrypto++
  -lcrypto++  
  arm@chrome~$ pkg-config --print-variables libcrypto++
  exec_prefix
  prefix
  libdir
  includedir
  arm@chrome~$ pkg-config --variable=includedir libcrypto++
  /usr/include


> 
>  - Second, your logic assumes that libcrypto is called libcrypto++
>    while the crux of the matter is that on some platforms it is named
>    libcryptopp, on others it's called libcrypto++. Of course, this can
>    be solved in the configure.ac by calling PKG_CHECK_MODULES() for
>    both.

Looking at configure.ac I think there's another assumption baked in
too.  The compile test uses:

  LDFLAGS="$LDFLAGS -lcryptopp -lpthread"

> 
>  - Third, the upstream version of libcrypto++ does *not* install a
>    pkg-config file. The Debian packagers have added one, so you
>    probably have one on your Debian system, but if you build
>    libcrypto++ from source and simply "make install" it, you won't have
>    a .pc file that describes it for pkg-config.
> 
> The last point is the very reason why my patch didn't switch to simply
> use pkg-config.
> 

Well that sucks.  What about a command line option to configure to
specify the libcrypto++ include path?  My issue here is that if you
have the headers in a non standard location (like $HOME/include), the
compiler probably won't know how to find them either, and the compile
check will fail at configure time.

I'd like to change the -isystem to a plain -I too.  I think I added
that because the source code used #include "foo.h" instead of 
#include <foo.h> and I didn't want to make any source code changes
with the automake changes. 

-Allen

  parent reply	other threads:[~2016-04-21 18:13 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-19 20:25 [tegrarcm PATCH] Don't assume cryptopp is system-wide installed Thomas Petazzoni
     [not found] ` <1461097517-21626-1-git-send-email-thomas.petazzoni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
2016-04-19 22:32   ` Stephen Warren
     [not found]     ` <5716B20E.8050607-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2016-04-19 22:50       ` Allen Martin
2016-04-19 23:57       ` Allen Martin
     [not found]         ` <20160419235745.GA28796-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2016-04-20  9:27           ` Thomas Petazzoni
     [not found]             ` <20160420112735.16eca48a-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
2016-04-21 18:13               ` Allen Martin [this message]
     [not found]                 ` <20160421181359.GA17433-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2016-04-21 19:24                   ` Thomas Petazzoni

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160421181359.GA17433@nvidia.com \
    --to=amartin-ddmlm1+adcrqt0dzr+alfa@public.gmane.org \
    --cc=linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org \
    --cc=thomas.petazzoni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.