gnutls-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: wrong gnutls.pc


From: Vincent Torri
Subject: Re: wrong gnutls.pc
Date: Fri, 26 Feb 2010 22:10:02 +0100



On Fri, Feb 26, 2010 at 7:30 PM, Andreas Metzler <address@hidden> wrote:
On 2010-02-26 Vincent Torri <address@hidden> wrote:
> Hey,
>
> compiling libcurl on Windows with MinGW leads to undefined symbols. The
> problem is in a bug in gnutls.pc. Indeed libgcrypt is a required dependency
> (btw, it is not checked in gnutls/lib/configure.ac. I think that it must be
> checked there. The library has a libgcrypt-config to  get cflags and libs).
> Hence, -lgcrypt must appear in the Libs.private field of gnutls.pc

Hello,

This broke somewhere after 2.6.6. 2.6.6 still has
Libs: -L${libdir} -lgnutls
Libs.private: -L${exec_prefix}/lib -lgnutls -lgcrypt  -L/usr/lib -ltasn1

but e.g. 2.7.11 is missing -lgcrypt in Libs.private.

I will try to investigate further this weekend.

> * in Libs.private of gnutls.pc.in, @LIBGNUTLS_LIBS@ is added, which means,
> according to its definition, that -lgnutls appears in Libs.private, which is
> useless.

It does not hurt either, pkg-config strips the duplicates.

it does not hurt, but it is not clean. I can always hack anything so that it works. I have no problem with linking with gnutls on windows. modifying LDFLAGS, hacking libcurl configure stuff, modifying by hand gnutls.pc, etc... If I send that mail, it's for the correct fix to be done. If you don't care, no problem. I can leave without the proper fix.

>  * libtasn1 is not checked with pkg-config if it exists (well, i don't see
> anything in gnutls/lib/configure.ac).

tasn is searched for with AC_LIB_HAVE_LINKFLAGS. See
./lib/m4/hooks.m4.

ok.

> If it exists, 'libtasn1' must appear
> in the Requires.private field (or Requires field if you support pkg-config <
> 0.22).

It does.

no it does not. the field *****Requires.private*****, and not Libs.private, does not appear in the .pc
 
> If it does not exists, i think that you link directly against your
> own libtasn2 code, so @LTLIBTASN1@ should not appear in Libs.private

This seems to work correctly for me, too.

sure, but having libtasn1 in Requires.private instead of having -ltasn1 in Libs.private is different. pkg-config takes care of the possible dependencies with the Requires.private field. Look at pkg-config documentation. By doing what you do, you can broke linking with future versions of libtasn1 if it has dependencies.

Vincent Torri

reply via email to

[Prev in Thread] Current Thread [Next in Thread]