R SIG Debian - Aug 2021 - Configure error: checking if libcurl supports https... no --- slight update.

Hi Rolf,

Am Montag, 30. August 2021, 07:42:56 CEST schrieb Rolf
Turner:
> Hi All,
> 
> I just thought I'd let you know that I've tried a couple of other
> things.  No real progress, but.
> 
> (1) In respect of just-plain-curl: to make the issue clearer, I tried
> 
>     curl --version
> 
> and got:
> > > curl: /usr/local/lib/libcurl.so.4: no version information
available
> > > (required by curl)
> > 
> > curl: symbol lookup error: curl: undefined symbol: curl_mime_free,
> > version CURL_OPENSSL_4
> 
> I found that there was another, apparently newer, version of
> libcurl.so.4 in /usr/lib/x86_64-linux-gnu.  I realised that I did
> not have /usr/lib/x86_64-linux-gnu in my LD_LIBRARY_PATH.  So I put it
> into that path (*before* /usr/local/lib) and "curl --version" now
> 
> seems to be OK and gives:
> > curl 7.68.0 (x86_64-pc-linux-gnu) libcurl/7.68.0 OpenSSL/1.1.1f
> > zlib/1.2.11 brotli/1.0.7 libidn2/2.2.0 libpsl/0.21.0
> > (+libidn2/2.2.0) libssh/0.9.3/openssl/zlib nghttp2/1.40.0
> > librtmp/2.3 Release-Date: 2020-01-08 Protocols: dict file ftp ftps
> > gopher http https imap imaps ldap ldaps pop3 pop3s rtmp rtsp scp
> > sftp smb smbs smtp smtps telnet tftp Features: AsynchDNS brotli
> > GSS-API HTTP2 HTTPS-proxy IDN IPv6 Kerberos Largefile libz NTLM
> > NTLM_WB PSL SPNEGO SSL TLS-SRP UnixSockets
> 
> which verbose, but I guess that's alright.
That may be OK for your the curl binary you are using (likely /usr/local/bin/
curl, you still owe use the output of 'which curl'.

But it seems you still have a curl/libcurl version in /usr/local that you 
should get rid of, as it gets in the way of configuring R.

Johannes
> 
> (2) In respect of libcurl and https:
> 
> I did a web search on "libcurl >= 7.28.0 library and headers are
> required" and after much thrashing around found what looked like a
> useful hit at https://www.xspdf.com/help/51318770.html .
> 
> The problem(s) described are exactly the same as mine.  Different
> correspondents report different results; one person said that
> installing libcurl4-openssl-dev solved the problem, another said that
> it didn't but that libcurl4-gnutls-dev did work.
> 
> It was nice to know that I am not alone, but neither of the foregoing
> solutions worked for me.  Then another correspondent suggested that the
> problem might be with the gcc variant.  I thought that this was
> promising.
> 
> I found that my gcc version was 9.3.0.  I found that the latest version
> seemed to be 11.2, so I tried to upgrade.  The process seemed to be
> endlessly complicated but I eventually got a new version such that
> 
>    gcc --version
> 
> gives "(Ubuntu 11.1.0-1ubuntu1~20.04) 11.1.0".  (11.1 not 11.2
??? Oh,
> well.)
> 
> But then I tried the configure step again, with the new gcc in place,
> and got the same old error.  Story of my life.
> 
> I'm going mad, *mad* I tell you!!! :-)
> 
> cheers,
> 
> Rolf

-- 
Johannes Ranke
Wissenschaftlicher Berater
07624 8099027
https://jrwb.de

On Mon, 30 Aug 2021 08:00:34 +0200
Johannes Ranke <johannes.ranke at jrwb.de> wrote:
> Hi Rolf,
> 
> Am Montag, 30. August 2021, 07:42:56 CEST schrieb Rolf Turner:
> > Hi All,
> > 
> > I just thought I'd let you know that I've tried a couple of
other
> > things.  No real progress, but.
> > 
> > (1) In respect of just-plain-curl: to make the issue clearer, I
> > tried
> > 
> >     curl --version
> > 
> > and got:
> > > > curl: /usr/local/lib/libcurl.so.4: no version information
> > > > available (required by curl)
> > > 
> > > curl: symbol lookup error: curl: undefined symbol:
curl_mime_free,
> > > version CURL_OPENSSL_4
> > 
> > I found that there was another, apparently newer, version of
> > libcurl.so.4 in /usr/lib/x86_64-linux-gnu.  I realised that I did
> > not have /usr/lib/x86_64-linux-gnu in my LD_LIBRARY_PATH.  So I put
> > it into that path (*before* /usr/local/lib) and "curl
--version" now
> > 
> > seems to be OK and gives:
> > > curl 7.68.0 (x86_64-pc-linux-gnu) libcurl/7.68.0 OpenSSL/1.1.1f
> > > zlib/1.2.11 brotli/1.0.7 libidn2/2.2.0 libpsl/0.21.0
> > > (+libidn2/2.2.0) libssh/0.9.3/openssl/zlib nghttp2/1.40.0
> > > librtmp/2.3 Release-Date: 2020-01-08 Protocols: dict file ftp
ftps
> > > gopher http https imap imaps ldap ldaps pop3 pop3s rtmp rtsp scp
> > > sftp smb smbs smtp smtps telnet tftp Features: AsynchDNS brotli
> > > GSS-API HTTP2 HTTPS-proxy IDN IPv6 Kerberos Largefile libz NTLM
> > > NTLM_WB PSL SPNEGO SSL TLS-SRP UnixSockets
> > 
> > which verbose, but I guess that's alright.
> 
> That may be OK for your the curl binary you are using (likely
> /usr/local/bin/ curl, you still owe use the output of 'which curl'.
Actually "which curl" yields "/usr/bin/curl".  Not that it
really
matters (???).
> But it seems you still have a curl/libcurl version in /usr/local that
> you should get rid of, as it gets in the way of configuring R.
I don't think so.  I did "sudo find /usr -name "*curl*"
-print".  The
results are attached in the file "curlSearch.txt".  I am too ignorant
to discern what might be problematic, but nothing obvious leaps out at
me.  Could the stuff in /usr/local/include/curl be a source of
difficulty?

 cheers,

Rolf

-- 
Honorary Research Fellow
Department of Statistics
University of Auckland
Phone: +64-9-373-7599 ext. 88276

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: curlSearch.txt
URL:
<https://stat.ethz.ch/pipermail/r-sig-debian/attachments/20210831/0a32397d/attachment.txt>