Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
Error building cURL 7.61.0 on SLES 11 SP3 #2890
I did this
I recently tried building 7.61.0 but it threw an error. cURL 7.60.0 works just fine on this machine, but the OS is a bit old, so I'm wondering if I've finally hit a "final" version of cURL for it?
as my compiler on SLES 11 SP3, I configured cURL with:
Configure succeeds, but on
NOTE: I mainly build cURL so that I can add OpenDAP support to netCDF in a set of base libraries for a climate model. I don't really need cURL to do much fancy, so I'm willing to --disable anything you might like me to try.
I expected the following
Well, the make to succeed.
Trying to build 7.61.0
Further information. cURL 7.61.0 built fine on a SLES12 SP3 machine. In doing the build I noticed that SLES 11 said:
And on SLES 12, it seemed to "skip" the vauth/vtls build:
With 7.60.0 on SLES11, I get:
So it has the same TLS-SRP support indicator, but it also doesn't build into vauth/vtls.
Looking at the systems, the SLES 11 has gnutls 2.4.1 and SLES 12 has gnutls 3.3.27. Would that matter?
So this looks like a problem with your OpenSSL version. We changed how we use the engine features because it is provided by default in openssl since a while back. Did you make a special build of OpenSSL without it? What openssl version is this?
Looks to be:
The machines I can build on:
As I said, old OS.
I'm guessing I might have to degrade cURL on the SLES 11 machine? I'm not sure the admins will want to upgrade OpenSSL if possible. (It's a supercomputing cluster that will eventually move to SLES 12).
Or is there a flag I could pass to avoid this?
so I'm a little puzzled why it tries to use this with OpenSSL 0.9.8j which presumably doesn't have it. Maybe
curl doesn't really care about the age of your OS. It builds on way older installs than yours too. It should build on anything close to posix with a c89 compiler. What is sometimes problematic on the old ones is the 3rd party libs and the versions of them, as curl has a lowest-version supported for each of them.
A big challenge with the oldies is that they're less tested and used so build errors tend to sneak in more often just because it was so long time since someone verified the build on that system.
Hmm. Well, I do see a lot of OpenSSL changes here: 38203f1, which is why I assume my 7.60.0 build has these lines:
in the configure output, but 7.61.0 doesn't?
As you are the expert, I'm attaching my config.log and make logs from builds of 7.60.0 and 7.61.0 on the same machine with the same compilers. Hopefully you can see something pertinent.
Also, I don't know if this could cause it, but on this system there does seem to be a couple libopenssl:
But only one has the devel package, which is why I assume configure is seeing the 0.9.8?
I can also report that if I try to build with:
Which is true. The
Yes, and that change made the engine support require OpenSSL 1.0.1 or later. So for your 0.9.8, it would not use it. But still it does...
That is likely to be the problem. It could be that configure finds one lib to setup things for, and then when you build curl it compiles and links with another and thus you get compiler errors.
That's not a crash, that's a compiler error. But it looks like we broke compatibility with really old gnutls versions a while ago with e644866 (curl 7.39.0)