GnuTLS 2.8.6

[Simon Josefsson]

Andreas Metzler <ametzler at downhill.at.eu.org> writes:

> On 2010-03-21 Simon Josefsson <simon at josefsson.org> wrote:
>> Andreas Metzler <ametzler at downhill.at.eu.org> writes:
> [...]
>> > -  AC_LIB_HAVE_LINKFLAGS(gcrypt,, [#include <gcrypt.h>],
>> > +  AC_LIB_HAVE_LINKFLAGS([gcrypt], [gpg-error], [#include <gcrypt.h>],
> [...]
>> > What problem is trying to solve?
>
>> GnuTLS doesn't build on Solaris without that.
>
> I am surprised. Afaiui AC_LIB_HAVE_LINKFLAGS parses the libtool la files
> and adds any dependency_libs. Is it possible that this only happened
> on incomplete installations (gcrypt la file not installed)? On Debian
> we actively work around this "feature" by editing the gcrypt la file and
> deleting the dependency_libs.

I saw the problem on at least two Solaris systems, and on one of the
systems I built libgpg-error+libgcrypt+gnutls from scratch and didn't
remove any *.la files.  Generally, I think the change above is actually
The Right Thing because libgpg-error IS a dependency of libgcrypt.
>
>> > Gnutls does not uses gpg-error functions, but ends up being linked
>> > against gpg-error even on architecures which do not require linkage
>> > against indirect dependencies.
>
>> Does that cause any problem?
> [...]
>
> Unnecessary linkage is a problem for distributors of binary packages
> since it complicates package depencies. This makes the installation
> program job a lot harder (and more expensive) than necessary. A second
> negative implication is that transitions caused by soname changes are
> harder since they involve more packages. (The second one shouldn't be
> a issue here, since libgpg-error upstream has promised that there
> won't be a soname bump, ever.)

I don't know how to resolve that and also making things work on Solaris.
As far as I can tell, building on Solaris seems more important than an
optimization for one particular distribution.

Further, if you don't have the fix above, you may run into problems with
binutils-gold which really needs the explicit dependency:
<http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=556345>.  There I
solved the same problem by applying a similar patch that was used here,
IIRC.

/Simon