[PATCH] Re: 4.2.0 compile error on our centos-6 and centos-7 systems (gnutls related)

[Thomas Schulz]

> On Thu, 2015-03-12 at 17:33 +1300, Andrew Bartlett wrote:
>> On Wed, 2015-03-11 at 10:46 -0400, Thomas Schulz wrote:
>>>> On Tue, 2015-03-10 at 19:35 +0100, Andreas Schneider wrote:
>>>>> On Wednesday 11 March 2015 07:20:13 Andrew Bartlett wrote:
>>>>>> On Mon, 2015-03-09 at 21:21 +0100, Andreas Schneider wrote:
>>>>>>>>From 3fa45a6301607cda2a632c0102768576db3c65a6 Mon Sep 17 00:00:00 2001
>>>>>>> 
>>>>>>> From: Andreas Schneider <asn at samba.org>
>>>>>>> 
>>>>>>> Date: Mon, 9 Mar 2015 21:14:19 +0100
>>>>>>> 
>>>>>>> Subject: [PATCH 3/3] s4-tls: Remove obsolete gcrypt support.
>>>>>>> 
>>>>>>> BUG: https://bugzilla.samba.org/show_bug.cgi?id=11135
>>>>>>> 
>>>>>>> Since GnuTLS 3.0 nettle is used instead of gcrypt.
>>>>>> 
>>>>>> Shouldn't this be conditional on the version of GnuTLS?
>>>>> 
>>>>> We only call one function of grcypt which we do not really have to call. 
>>>>> GnuTLS should correclty initialize gcrypt if it uses it. But since quite some 
>>>>> time (2010/2011) GnuTLS dropped support for gcrypt. I don't see a reason why 
>>>>> we should still link against it.
>>>> 
>>>> Because if we don't set that flag, we had testsuites bog down as it
>>>> foolishly demanded keys from /dev/random, as I recall it.  See
>>>> b1ff79dbb246e717fc4a62c7a615ca7ce9ccc302
>>>> 
>>>> That is, to remove that linkage, please also bump the minimum version to
>>>> 3.0.
>>>> 
>>>> Thanks!
>>>> 
>>>> Andrew Bartlett
>>> 
>>> You probably should make things conditional on the version of GnuTLS.
>>> 
>>> Consider the case where the latest version of GnuTLS is obtained and
>>> installed because the original version is way too old. This can leave a
>>> very old version of libgcrypt installed. This can cause the build to fail.
>>> 
>>> I received the following error:
>>> 
>>> ../source4/lib/tls/tlscert.c", line 74: undefined symbol:
>>>    GCRYCTL_ENABLE_QUICK_RANDOM
>> 
>> Thanks.  Can you try the attached patches in this situation?
>> 
>> I've built Centos7 and Fedora 21 build boxes, but these never showed the
>> original failure, so I'm assuming it was just the --disable-gnutls some
>> folks had in their standard configure lines.
> 
> I've uploaded this patch to bug.  
> 
> Andreas,
> 
> Please review/push if you are happy, it seems to work well on the
> systems I have access to. 
> 
> Thanks,
> 
> Andrew Bartlett

Some news. I expect that this will be good for all linux systems. I ran
into a little strangeness on Solaris 10.

The first problem was that configure kept acting like it was not finding
the gnutls.pc file. A previous verssion of the patch allowed configure
to continue if that was not found. I finally took a hint from some error
messages from some other packages and removed the line

URL: http://www.gnutls.org

from the gnutls.pc file. That fixed that problem.

Running make, everything compiled but linking failed with a problem that
looked to have no relation to this bug and patch. The error was:

[3580/3977] Linking default/source4/client/smbclient4
Undefined			first referenced
 symbol  			    in file
strsep                              default/source4/librpc/libdcerpc.so
ld: fatal: Symbol referencing errors. No output written to /home/projects
  /tools/samba/samba-4.2.0.i386sc.pt/bin/default/source4/client/smbclient4

BUT! I can get it to build if I do the following:

After running  configure, hide away the new libraries and .h files from
the new gnutls install and make the extremely old ones available.
Start the make and wait until the linking dies due to not finding the
many routines that the old gnutls does not have.
Put back the new gnutls.
Restart the make. It now continues and links the failed link and continues
to be able to link default/source4/client/smbclient4.

Don't ask how I came up with that procedure. I think that I am going to
eat some of those cherries you keep picking, as soon as I can figure out
how to download them. And then I am going to go to bed!

Tom Schulz
Applied Dynamics Intl.
schulz at adi.com