[gnutls-devel] gnutls.pc includes invalid flags
n.mavrogiannopoulos at gmail.com
Sat Mar 18 19:23:14 CET 2017
On Sat, 2017-03-18 at 13:52 +0100, Andreas Metzler wrote:
> On 2017-03-17 Nikos Mavrogiannopoulos <nmav at gnutls.org> wrote:
> > On Thu, Mar 16, 2017 at 6:03 PM, Andreas Metzler <ametzler at bebt.de>
> > wrote:
> > > this is https://bugs.debian.org/857943 reported by Aaron M. Ucko:
> > > ----------------
> > > he output of `pkg-config gnutls --libs --static` includes a flag
> > > of
> > > the form -R/usr/lib/$DEB_HOST_MULTIARCH, which is not only
> > > superfluous
> > > but also outright broken without a leading -Wl,:
> > > $ gcc `pkg-config gnutls --libs --static`
> > > gcc: error: unrecognized command line option ‘-R’; did you mean
> > > ‘-R’?
> > > $ pkg-config gnutls --libs --static
> > > -lgnutls -lz -R/usr/lib/x86_64-linux-gnu -lp11-kit -lgmp
> > > -lnettle -lhogweed -lgmp -lnettle -ltasn1 -lidn -lp11-kit -lz
> > > ----------------
> > > Attached patch works for me.
> > > (I am not totally sure whether it is useful to carter for
> > > incomplete
> > > pkg-config setups at all. If there is no zlib.pc, the user will
> > > probably
> > > not install gnutls.pc either.)
> > I'm thinking that this may apply to all the LT variables used
> > Libs.private.
> I think so, too. It just has not hit us at Debian yet since the other
> @LT variables in gnutls.pc.in expand to empty strings in our builds.
> > Would it still work if we use the non LT version of the
> > variables (e.g., LIBZ in that case?)
> It probably would work, but definitely is not pretty, "./configure
> --libdir=/usr/lib/x86_64-linux-gnu" will produce these output
> when libz.so is in /usr/lib/x86_64-linux-gnu (which is in the
> linker search path):
> LIBZ=/usr/lib/x86_64-linux-gnu/libz.so -Wl,-rpath
> LTLIBZ=-L/usr/lib/x86_64-linux-gnu -lz -R/usr/lib/x86_64-linux-gnu
> This seems to be a general problem with AC_LIB_HAVE_LINKFLAGS.
I've modified all the flags to remove the libtool variables, and added
a small test for compilation using these flags:
This will not address the "ugliness" but at least would ensure that
these flags are reasonable and lead to compilation. If you have any
suggestion on something we could additionally check with pkg-config,
let me know.
More information about the Gnutls-devel