Skip to content

Configure error: checking if libcurl supports https... no

20 messages · Rolf Turner, Dirk Eddelbuettel, Michael Mahoney +2 more

#
I asked this question a short while ago on the R-help list, and
received an off-list reply from Ivan Krylov, suggesting that it would
be better to ask on r-sig-debian.  So here goes:  to set the context,
I'm running Ubuntu 20.04, with a Mate 1.24.0 desktop.

The question is long and complicated; you will need a great deal of
patience to plough through it.  (Sorry 'bout that!)

I'm getting results from a package (written by my very good self) which
differ (rather mysteriously) from results that I got a few weeks ago,
and the only thing that I can think of that's changed is the version of
R (from 4.1.0 to 4.4.1).

So I wanted to install 4.1.0 and play around with that, to see if that
is indeed the explanation.  (If that is so, a whole new set of
questions would be raised, but let's not go there, for the moment.)  I
downloaded the tarball and set about installing 4.1.0 from source.  But
the configure step threw an error, as given in the subject line of
this message.  The error went on:
A bit of web searching turned up the advice to re-install curl
using

    sudo apt-get install curl

but when I did that I was informed that:
Prof. Krylov suggested in his off-list email that I should do:

    sudo apt install libcurl-dev

So I did that (effectively; but see below) and what I did seemed to run
without (too much) complaint, but the configure error persisted.

When I tried "sudo apt install libcurl-dev" I got a message to the
effect that "libcurl-dev" was ambiguous.  Explicitly:
Hmmm.  Which one?  No idea, really, but the config.log file was
full of stuff relating to errors from "openssl.c" (*way* beyond my pay
grade!!!) so I thought I'd try the first one.

As indicated above,

    sudo apt-get install libcurl4-openssl-dev

seemed to run without complaint, although it said
which made me think that maybe I should have used "libcurl4-gnutls-dev".
But I carried on, and the command ran (without --- further ---
complaint).  However, as I said, the configuration error persisted.

So I then tried:

   sudo apt remove libcurl4-openssl-dev

and got a whole lot of ominous warnings, starting:
(There was more ....)

Having done that I crossed my fingers and tried:

    sudo apt-get install libcurl4-gnutls-dev

and got
So I then tried *removing* libcurl4-gnutls-dev (that seemed to work!)
and then re-installing it.  *That* seemed to work too, and there were
no more messages about "manually installed".

But the configure error *still* persisted!!!

I am now out of ideas, at my wits' end, at the end of my tether, and a
few other things.

Can anyone suggest anything else that I might try?  If so, can I
very humbly exhort you to please (*please* *PLEASE*) present it in very
simple terms if you can. (I am a Bear of Very Little Brain, and long
words bother me.) A step-by-step recipe would be appreciated.

As you can see from this long-winded question, I really have no idea at
all what I am doing, and am basically issuing commands by rote,
hammering and hoping.  (With the hopes always being dashed. :-( )
Consequently any advice, that presupposes that I have *insight* into
the processes that I am invoking, is unlikely to be of any use to me.

cheers,

Rolf Turner
#
Rolf,

Asking here is the Right Thing (TM) but I am in at this moment between two
differen things (one of them being dinner...) so I have to come back to this
but regarding
I have also found that confusing. I somewhat recently helped a very motivated
undergrad getting an R package working which required a (available for
Ubuntu, good thing there) library which itself libcurl4-gnutls-dev. I happen
to have libcurl4-openssl-dev installed and they don't coexist ... so I opted
to doing that work with the undergrad in a Docker environment.

Long story short, I would suggest trying to see if you can work with / can
get what you need adjusted to libcurl4-openssl-dev.   On my Ubuntu (21.04)
system:

  edd at rob:~$ apt-cache rdepends libcurl4-openssl-dev | wc -l
  22
  edd at rob:~$ apt-cache rdepends libcurl4-gnutls-dev | wc -l
  45
  edd at rob:~$

So maybe my preference is on the wrong side of the tracks too. I don't fully
understand why these cannot coexist...

Dirk
#
On Sat, 28 Aug 2021 19:55:12 -0500
Dirk Eddelbuettel <edd at debian.org> wrote:

            
<SNIP>

Thanks Dirk.  I might try removing libcurl4-gnutls-dev again,
and installing libcurl4-openssl-dev again, while I'm waiting to hear
more from you.  Don't like my chances, but.
Sheesh!  If *you* don't understand, what hope is there for the rest of
us, me in particular?

cheers,

Rolf
#
Rolf,

I am truly sorry but I am getting lost in your original message. Could you
follow-up and describe (concisely, if possible) what your question is?  Is it
 - installing 4.1.1 or 4.1.0
 - developing a package of yours
 - installing a package ?

You seem to interweave a few strands in ways that make it less clear exactly
what is holding you back.
On 29 August 2021 at 15:11, Rolf Turner wrote:
| > So maybe my preference is on the wrong side of the tracks too. I
| > don't fully understand why these cannot coexist...
| 
| Sheesh!  If *you* don't understand, what hope is there for the rest of
| us, me in particular?

Sometimes it is a simple lack of resources / time / effort / merit. Something
I meant to tackle is to allow r-base-core to coexist with a (to be written
package) r-base-devel but doing that _cleanly_ with the expect robustness is
a lot of work so I have yet to do it, even after ~ 20 years of working on R
and the r-{base,doc}-* packages as well as many r-cran-* ones.

Dirk
#
On Sat, 28 Aug 2021 22:33:08 -0500
Dirk Eddelbuettel <edd at debian.org> wrote:

            
Sorry if I over-egged my explanation.

* I am trying to install R 4.1.0 (the previous version of R).
  I have the current version, R 4.1.1 (readily available as a Linux
  binary) up and going; no problema.

* My desire to install 4.1.0 was *motivated* by a strange
  conundrum with respect to a package that I am developing.
  But that's *not* actually relevant at the moment.

* I successfully downloaded the source for R 4.1.0 and started
  the configure -> make sequence.  But things came to a halt with the
  configure error shown in the subject line.

* I then fooled around with installing/uninstalling various flavours
  of libcurl.dev to see if I could get rid of the configure error.
  Nothing worked.

I hope that my problem is clear now.

cheers,

Rolf
#
Hi,

for what it's worth, on a Debian bullseye system, configuring the R 4.1.0 
tarball works fine:

$ wget https://cran.r-project.org/src/base/R-4/R-4.1.0.tar.gz
$ tar xf R-4.1.0.tar.gz
$ cd R-4.1.0/
$ ./configure

...
checking if libcurl supports https... yes
...

with libcurl4 and libcurl4-gnutls-dev installed. I believe this should also 
work on Ubuntu.

You can try

$ sudo apt build-dep r-base

to pull in all build dependencies specified by Dirks R debs, and try again.

Johannes






Am Sonntag, 29. August 2021, 08:49:19 CEST schrieb Rolf Turner:
#
On Sun, 29 Aug 2021 15:11:33 +1200
Rolf Turner <r.turner at auckland.ac.nz> wrote:
<SNIP>
<SNIP>

I tried this just now.  No help at all.  I was right not to like my
chances!

cheers,

Rolf
#
On Sun, 29 Aug 2021 10:16:16 +0200
Johannes Ranke <johannes.ranke at jrwb.de> wrote:

            
Hmm.  I may not have had libcurl4 properly installed; tried to install
it (to make sure) and got a message about it having been "manually
installed". (No idea how the <expletive deleted> that happened, but
ne'er mind.) So I removed libcurl4, re-installed it, and tried the
configure step again.  Same result, same error.
Thanks for the suggestion.  I did

   sudo apt build-dep r-base

as instructed.

I then noticed that I could not run R --- got a "permission denied"
error.  So I next did:

   sudo apt-get install r-base

After quite a while and after an enourmous amount of incomprehensible
output had been spewed out onto the screen, the command appeared to
succeed and I could run R again.

I then tried the configure step, for building R 4.1.0 from source,
again.  Same result, same error.

Why, in the name of all that's unholy, do these things happen to *me*?

cheers,

Rolf Turner

P.S. Clearly there must be something broken in my system, but how on
earth do I track down what's wrong?

R. T.
#
Am Sonntag, 29. August 2021, 11:01:43 CEST schrieb Rolf Turner:
...
I assume this pulled in some unrelated packages. As you do not mention any 
output, I assume there was no error.
...
One reason for what you see could be that you have previously compiled and 
installed curl from source (which will also build and install libcurl), and 
this local installation does not have ssl support.

One check that I can think of is to run

$ which curl

which returns

/usr/bin/curl

if you only have the Ubuntu package installed.

Johannes
#
Forgive me if I'm missing something here, but do you need to install
from source or do you just need R 4.1.0?

If the latter, my understanding is that you should be able to get R
version 4.1.0 on Ubuntu distributions via:

sudo apt install r-base=4.1.0-1.2004.0 r-recommended=4.1.0-1.2004.0
r-base-html=4.1.0-1.2004.0 r-doc-html=4.1.0-1.2004.0

Assuming you're using the official ppa (and uninstalled the newer
versions first).

If all you need is R 4.1.0, this might be a bit less temperamental.

Thanks,

Michael Mahoney
781-812-8842 | mike.mahoney.218 at gmail.com
Website | LinkedIn | GitHub

Michael Mahoney
781-812-8842 | mike.mahoney.218 at gmail.com
Website | LinkedIn | GitHub
On Sun, Aug 29, 2021 at 7:25 AM Johannes Ranke <johannes.ranke at jrwb.de> wrote:
#
On 29 August 2021 at 08:06, Michael Mahoney wrote:
| Forgive me if I'm missing something here, but do you need to install
| from source or do you just need R 4.1.0?
| 
| If the latter, my understanding is that you should be able to get R
| version 4.1.0 on Ubuntu distributions via:

An even easier alternative is to just run a pre-made Docker version, and then
run your local package tests in that.

Dirk
#
Dear Rolf,

Sorry you're still having problems with this. If you still would like
to build R-4.1.0 from source (instead of using a Docker image or some
binary package), could you share your config.log using a service like
https://paste.debian.net/ ?

It's also... interesting that you got a "permission denied" while
trying to run R. Which version of R was that? (`which R` may help to
find out.)
#
On Sun, 29 Aug 2021 08:06:00 -0400
Michael Mahoney <mike.mahoney.218 at gmail.com> wrote:

            
I just need R 4.1.0.  Installing from source is/was only a means to
this end.

However I could not find (despite substantial web-searching) any way to
install a pre-built binary of anything but the *current* release.
I *assume* that I'm using "the official ppa", but I have no idea what
that means!!!  Can you elaborate?

Can you also elaborate as to how to "uninstall the newer versions"?
Sorry to be so demanding and to be such a thicko.
There is a problem however.  I really want to have 4.1.0 *available*,
but to keep 4.1.1 as being the "real" R.

If I were to succeed in "installing" from source, I could do just
the configure/make steps and omit the "make install" step.  I could
then run R 4.1.0 from the bin directory that is created.  I think!
Rather than putting the executable into /usr/bin, so that /usr/bin/R
would remain the 4.1.1 version.

Is there any way/can you see any way to have both the 4.1.1 and the
4.1.0 versions available, when the 4.1.0 version is installed from
binary in the manner that you suggest?

Again, sorry to be so demanding and to be such a thicko.

cheers,

Rolf
#
On Sun, 29 Aug 2021 07:42:08 -0500
Dirk Eddelbuettel <edd at debian.org> wrote:

            
Sounds like a Good Idea, but oh God.  It's daunting.  I have no idea
what Docker is, or how to use it ....

Did some web searching, and found *some* instructions.  Started off by
looking at the instructions for installing Docker on Ubuntu.  Did the
update step and the set-up-repository step.  That seemed to go OK.

Then I came to the "Add Docker?s official GPG key:" step.  Issued the
specified command
And of course all hell broke loose.  Since curl is involved.  I got:
So I'm back to the fact that my system is stuffed w.r.t. curl, but I
have no idea how to track down what's wrong. :-(

cheers,

Rolf
#
...
so here we have evidence that indeed you have a locally compiled curl version 
on your system in addition to the Ubuntu one (which would not put anything 
into /usr/local/lib).

So it seems that at some point you have downloaded curl sources and installed 
them into your system, and that this version (as it has no https support) got 
in the way configuring R 4.1.0.

If you still have the sources lying around, there is an uninstall target in 
the Makefile, so you should go to the source directory and do a

sudo make uninstall

to get rid of your local curl version in /usr/local/.

Johannes
#
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:
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:
which verbose, but I guess that's alright.

(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
#
Hi Rolf,

Am Montag, 30. August 2021, 07:42:56 CEST schrieb Rolf Turner:
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

  
    
#
On Mon, 30 Aug 2021 08:00:34 +0200
Johannes Ranke <johannes.ranke at jrwb.de> wrote:

            
Actually "which curl" yields "/usr/bin/curl".  Not that it really
matters (???).
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
#
Am Dienstag, 31. August 2021, 01:47:14 CEST schrieb Rolf Turner:
...
Good thought as far as I can tell. Unfortunately the attachment didn't get 
through.
Others on this list are far more qualified to answer this, but from my limited 
knowledge in this area I would say yes, it could.

Johannes
#
Oh, I just overlooked the attachement, it did get through. The listing clearly 
shows that you have a curl version in /usr/local/ that I would recommend to 
uninstall (preferably using make uninstall in the source directory) as 
suggested in my previous emails, as it is the likely cause of the configure 
error you came to report.

The Ubuntu curl/libcurl etc packages (that you should keep) provide the 
headers in /usr/include.

Johannes