Buy commercial curl support from WolfSSL. We help you work
out your issues, debug your libcurl applications, use the API, port to new
platforms, add new features and more. With a team lead by the curl founder
himself.
Re: How to build libcurl with OpenSSL without installing the latter?
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Daniel Stenberg via curl-library <curl-library_at_lists.haxx.se>
Date: Thu, 11 Nov 2021 09:51:16 +0100 (CET)
On Wed, 10 Nov 2021, ellie wrote:
>> Having configure checks fail to detect something optional is not a problem
>
> Well, it is a problem if what it fails on is what I want to use, which was
> the case here.
Yes, then you need to adjust the --with* or --enable-* options. It's not an
argument for adding --disable or --without options.
For example, you wanting to link with a static OpenSSL doesn't change how
configure finds OpenSSL's headers and verifies that it links and works. You
still point to its install "prefix" with --with-openssl=[prefix].
> I was under the assumption I can't install a Windows OpenSSL on a Linux host.
Sure you can. A common cross-build setup involves having a dedicated file tree
somewhere on the system that's setup to work for the target platform. Those
files won't work on the local system.
When you cross-compile, the cross-compiler and cross-linker can still link and
check things in that target-specific file tree.
> To be fair, I didn't actually try so maybe I should, good point. Still seems
> like a bit of a nonsensical workflow though. Why do I need an install when
> all I want is a static build with a static link that should only need the
> header files?
No, that's incorrect. A static build and a shared build both need headers and
the library itself to be present and their locations to be known. For
compiling and for linking. The main difference is how the generated output is
created from that linking process if shared or static - and also how it finds
or not finds additional dependencies automatically.
> So using none of these libraries EVEN IF PRESENT is the default? I don't
> think I saw that behavior, but I can check again if you're sure about that.
curl's configure picks NO SSL library by default and will error out if you
then don't ask for a build without SSL. So yes, I'm sure about that. (Unless
you use an older curl which used to look for OpenSSL by default.)
For some of the other libraries, configure will check for them and use them by
default without the need for any option but then why would configure find
libraries in your setup if you don't have them and curl can then use them?
Anyway, you can then of course explicitly disable those few libs. The summary
at the end of the configure run should give you the details you need of what's
included or not in the build.
> But blacklisting it all with those --without is both ugly, and a maintenance
> nightmare since I assume new external libs & features are added frequently.
Really? Have you now maintained your curl build for a few years and this is
your experience and feedback on the curl build process? Can you please mention
a few of those that we've added over, say, the last five years that caused you
this much grief?
Why is it double-checking the configure summary and just re-run it with
another option added if necessary such a nightmare ?
> I have also noticed as a side note that for a Windows build with autotools,
> it seems to be impossible to avoid including code that needs a link to
> crypt32/wincrypt, even when I want to use OpenSSL & custom cert store only.
> If there is an option to prevent that I didn't find it.
I don't know. This is Windows territory stuff that I'm not mastering. Maybe if
you extract this issue alone and ask on this mailing list someone can respond.
I suspect it now drowned deep in this thread which I bet not too many readers
actually read all the way through...
Date: Thu, 11 Nov 2021 09:51:16 +0100 (CET)
On Wed, 10 Nov 2021, ellie wrote:
>> Having configure checks fail to detect something optional is not a problem
>
> Well, it is a problem if what it fails on is what I want to use, which was
> the case here.
Yes, then you need to adjust the --with* or --enable-* options. It's not an
argument for adding --disable or --without options.
For example, you wanting to link with a static OpenSSL doesn't change how
configure finds OpenSSL's headers and verifies that it links and works. You
still point to its install "prefix" with --with-openssl=[prefix].
> I was under the assumption I can't install a Windows OpenSSL on a Linux host.
Sure you can. A common cross-build setup involves having a dedicated file tree
somewhere on the system that's setup to work for the target platform. Those
files won't work on the local system.
When you cross-compile, the cross-compiler and cross-linker can still link and
check things in that target-specific file tree.
> To be fair, I didn't actually try so maybe I should, good point. Still seems
> like a bit of a nonsensical workflow though. Why do I need an install when
> all I want is a static build with a static link that should only need the
> header files?
No, that's incorrect. A static build and a shared build both need headers and
the library itself to be present and their locations to be known. For
compiling and for linking. The main difference is how the generated output is
created from that linking process if shared or static - and also how it finds
or not finds additional dependencies automatically.
> So using none of these libraries EVEN IF PRESENT is the default? I don't
> think I saw that behavior, but I can check again if you're sure about that.
curl's configure picks NO SSL library by default and will error out if you
then don't ask for a build without SSL. So yes, I'm sure about that. (Unless
you use an older curl which used to look for OpenSSL by default.)
For some of the other libraries, configure will check for them and use them by
default without the need for any option but then why would configure find
libraries in your setup if you don't have them and curl can then use them?
Anyway, you can then of course explicitly disable those few libs. The summary
at the end of the configure run should give you the details you need of what's
included or not in the build.
> But blacklisting it all with those --without is both ugly, and a maintenance
> nightmare since I assume new external libs & features are added frequently.
Really? Have you now maintained your curl build for a few years and this is
your experience and feedback on the curl build process? Can you please mention
a few of those that we've added over, say, the last five years that caused you
this much grief?
Why is it double-checking the configure summary and just re-run it with
another option added if necessary such a nightmare ?
> I have also noticed as a side note that for a Windows build with autotools,
> it seems to be impossible to avoid including code that needs a link to
> crypt32/wincrypt, even when I want to use OpenSSL & custom cert store only.
> If there is an option to prevent that I didn't find it.
I don't know. This is Windows territory stuff that I'm not mastering. Maybe if
you extract this issue alone and ask on this mailing list someone can respond.
I suspect it now drowned deep in this thread which I bet not too many readers
actually read all the way through...
-- / daniel.haxx.se | Commercial curl support up to 24x7 is available! | Private help, bug fixes, support, ports, new features | https://curl.se/support.html -- Unsubscribe: https://lists.haxx.se/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.htmlReceived on 2021-11-11