bug#19168: undefined references to gnutls_pk_bits_to_sec_param etc

bug#19168: undefined references to gnutls_pk_bits_to_sec_param etc

[Glenn Morris]

Package: emacs
Version: 25.0.50

Current master on RHEL6.6 (or Trisquel 4.1 LTS), which has GnuTLS 2.8.5:

    gnutls.c:877: undefined reference to `gnutls_pk_bits_to_sec_param'
    gnutls.c:877: undefined reference to `gnutls_sec_param_get_name'
    gnutls.c:888: undefined reference to `gnutls_x509_crt_get_issuer_unique_id'
    gnutls.c:899: undefined reference to `gnutls_x509_crt_get_subject_unique_id'
    collect2: ld returned 1 exit status
    make[1]: *** [temacs] Error 1

configure accepts gnutls >= 2.6.6.

bug#19168: undefined references to gnutls_pk_bits_to_sec_param etc

[Lars Magne Ingebrigtsen]

Glenn Morris <rgm@gnu.org> writes:

> Package: emacs
> Version: 25.0.50
>
> Current master on RHEL6.6 (or Trisquel 4.1 LTS), which has GnuTLS 2.8.5:
>
>     gnutls.c:877: undefined reference to `gnutls_pk_bits_to_sec_param'
>     gnutls.c:877: undefined reference to `gnutls_sec_param_get_name'
>     gnutls.c:888: undefined reference to `gnutls_x509_crt_get_issuer_unique_id'
>     gnutls.c:899: undefined reference to `gnutls_x509_crt_get_subject_unique_id'
>     collect2: ld returned 1 exit status
>     make[1]: *** [temacs] Error 1
>
> configure accepts gnutls >= 2.6.6.

I implemented this on a machine with Debian Stale, so I thought I
was safe.  :-)  That's 2.12, apparently.

Does anybody know whether `gnutls_x509_crt_get_issuer_unique_id' (etc)
were available under different names in earlier gnutls versions?

I have to run now, so I won't be able to handle this until tomorrow.  If
anybody else wants to fix this in the meantime, please do.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#19168: undefined references to gnutls_pk_bits_to_sec_param etc

[Ted Zlatanov]

On Mon, 24 Nov 2014 18:33:48 +0100 Lars Magne Ingebrigtsen <larsi@gnus.org> wrote: 

LMI> Glenn Morris <rgm@gnu.org> writes:
>> Package: emacs
>> Version: 25.0.50
>> 
>> Current master on RHEL6.6 (or Trisquel 4.1 LTS), which has GnuTLS 2.8.5:
>> 
>> gnutls.c:877: undefined reference to `gnutls_pk_bits_to_sec_param'
>> gnutls.c:877: undefined reference to `gnutls_sec_param_get_name'
>> gnutls.c:888: undefined reference to `gnutls_x509_crt_get_issuer_unique_id'
>> gnutls.c:899: undefined reference to `gnutls_x509_crt_get_subject_unique_id'
>> collect2: ld returned 1 exit status
>> make[1]: *** [temacs] Error 1
>> 
>> configure accepts gnutls >= 2.6.6.

LMI> I implemented this on a machine with Debian Stale, so I thought I
LMI> was safe.  :-)  That's 2.12, apparently.

LMI> Does anybody know whether `gnutls_x509_crt_get_issuer_unique_id' (etc)
LMI> were available under different names in earlier gnutls versions?

LMI> I have to run now, so I won't be able to handle this until tomorrow.  If
LMI> anybody else wants to fix this in the meantime, please do.

I wrote a proposal on emacs-devel to require 3.x.  IMO that's the right
path here.

For instance, `gnutls_x509_crt_get_key_id' was available since 0.9.x but
the issuer and subject unique IDs were not until 2.11.  It's going to be
really annoying to support all those combinations of 2.x and 3.x.  See
http://gitorious.org/gnutls/gnutls/blobs/master/NEWS for the API details.

Ted

bug#19168: undefined references to gnutls_pk_bits_to_sec_param etc

[Lars Magne Ingebrigtsen]

Ted Zlatanov <tzz@lifelogs.com> writes:

> I wrote a proposal on emacs-devel to require 3.x.  IMO that's the right
> path here.

Debian Stale isn't on 3.x yet, so I think it's too soon.

> For instance, `gnutls_x509_crt_get_key_id' was available since 0.9.x but
> the issuer and subject unique IDs were not until 2.11.  It's going to be
> really annoying to support all those combinations of 2.x and 3.x.  See
> http://gitorious.org/gnutls/gnutls/blobs/master/NEWS for the API details.

Well, we could just #ifdef those calls away on older versions.  The
certificate display won't be as complete on older systems, but
networking will still work.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#19168: undefined references to gnutls_pk_bits_to_sec_param etc

[Lars Magne Ingebrigtsen]

Glenn Morris <rgm@gnu.org> writes:

> Package: emacs
> Version: 25.0.50
>
> Current master on RHEL6.6 (or Trisquel 4.1 LTS), which has GnuTLS 2.8.5:
>
>     gnutls.c:877: undefined reference to `gnutls_pk_bits_to_sec_param'
>     gnutls.c:877: undefined reference to `gnutls_sec_param_get_name'
>     gnutls.c:888: undefined reference to `gnutls_x509_crt_get_issuer_unique_id'
>     gnutls.c:899: undefined reference to `gnutls_x509_crt_get_subject_unique_id'
>     collect2: ld returned 1 exit status
>     make[1]: *** [temacs] Error 1
>
> configure accepts gnutls >= 2.6.6.

I've now pushed a fix that checks the version before compiling those
functions.  Does this fix the RHEL LTS compilation problem?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#19168: undefined references to gnutls_pk_bits_to_sec_param etc

[Ted Zlatanov]

On Tue, 25 Nov 2014 15:48:31 +0100 Lars Magne Ingebrigtsen <larsi@gnus.org> wrote: 

LMI> Ted Zlatanov <tzz@lifelogs.com> writes:
>> I wrote a proposal on emacs-devel to require 3.x.  IMO that's the right
>> path here.

LMI> Debian Stale isn't on 3.x yet, so I think it's too soon.

Bah.

>> For instance, `gnutls_x509_crt_get_key_id' was available since 0.9.x but
>> the issuer and subject unique IDs were not until 2.11.  It's going to be
>> really annoying to support all those combinations of 2.x and 3.x.  See
>> http://gitorious.org/gnutls/gnutls/blobs/master/NEWS for the API details.

LMI> Well, we could just #ifdef those calls away on older versions.  The
LMI> certificate display won't be as complete on older systems, but
LMI> networking will still work.

Hrm.

Ted "pffft"

bug#19168: undefined references to gnutls_pk_bits_to_sec_param etc

[Glenn Morris]

Lars Magne Ingebrigtsen wrote:

> I've now pushed a fix that checks the version before compiling those
> functions.  Does this fix the RHEL LTS compilation problem?

Yes thank you.

BTW, unrelated, but configure says this:

  checking for LIBGNUTLS... no
  checking for LIBGNUTLS... yes

which is a bit unclear...

bug#19168: undefined references to gnutls_pk_bits_to_sec_param etc

[Lars Magne Ingebrigtsen]

Glenn Morris <rgm@gnu.org> writes:

> BTW, unrelated, but configure says this:
>
>   checking for LIBGNUTLS... no
>   checking for LIBGNUTLS... yes
>
> which is a bit unclear...

Yes.  Is it the check for GNUTLS3 that fails, perhaps?  My autoconf-foo
is in the negative region, so I'm not sure what should be changed here...

HAVE_GNUTLS=no
HAVE_GNUTLS3=no
if test "${with_gnutls}" = "yes" ; then
  EMACS_CHECK_MODULES([LIBGNUTLS], [gnutls >= 3.0.0],
    [HAVE_GNUTLS3=yes], [HAVE_GNUTLS3=no])
  if test "${HAVE_GNUTLS3}" = "yes"; then
    AC_DEFINE(HAVE_GNUTLS3, 1, [Define if using GnuTLS v3.])
    HAVE_GNUTLS="yes"
  else
    EMACS_CHECK_MODULES([LIBGNUTLS], [gnutls >= 2.6.6],
      [HAVE_GNUTLS=yes], [HAVE_GNUTLS=no])
  fi
  if test "${HAVE_GNUTLS}" = "yes"; then
    AC_DEFINE(HAVE_GNUTLS, 1, [Define if using GnuTLS.])
  fi

  # Windows loads GnuTLS dynamically
  if test "${opsys}" = "mingw32"; then
    LIBGNUTLS_LIBS=
  fi
fi


-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no