New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Error building cURL 7.61.0 on SLES 11 SP3 #2890
Comments
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? |
Lines 1050 to 1053 in ba58ce6
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) |
Summed up, the problems shown in here so far has been too old dependencies. curl itself will build on these systems either without these dependencies or with updated versions of them. Closing this issue. |
Got the same error with 7.61.1 and tried 7.62.0 and it went through. Thanks for fixing it. |
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?
Using:
as my compiler on SLES 11 SP3, I configured cURL with:
Configure succeeds, but on
make
I get: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.
curl/libcurl version
Trying to build 7.61.0
operating system
The text was updated successfully, but these errors were encountered: