linux-tegra.vger.kernel.org archive mirror
 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).