[Libwebsockets] Openssl is too old to support lws_tls_vhost_cert_info
andy at warmcat.com
Wed Mar 2 05:54:07 CET 2022
On 3/2/22 04:36, Kyle Dias wrote:
> Hi Andy,
> After getting it to work for aarch64 I also needed to build a 32 bit arm
> version. However this one when building no matter what I have tried, it
> cannot find the openssl includes and cmake shows it is searching the
> correct directories. As you suggested I did the proper "hygiene"
You have to do that for any sane cross-build, otherwise you are doomed;
but it doesn't magically innoculate you against all other problems.
> although even with specifying the include directories it cannot find it.
> My cmake command is:
> cmake .. -DLWS_WITHOUT_EXTENSIONS=1 -DLWS_WITH_SHARED=OFF
> -DLWS_WITH_ZIP_FOPS=OFF -DLWS_WITH_ZLIB=OFF -DLWS_WITH_SSL=ON
Is that disk really mounted at "/media/di**a**sk5/..." ? Seems so.
> Although it shows it is searching correctly in cmake output:
> -- Found OpenSSL:
It seems to feel it found it.
> (found version "1.1.1m")
> OpenSSL include dir:
> OpenSSL libraries:
> Then all openssl files show not found
> -- Looking for openssl/ecdh.h
> -- Looking for openssl/ecdh.h - not found
> etc ...
exist on the disk?
Can your user open that in vim or whatever?
> Is there a different process or do I have to do something different for
> 32 bit arm? I assume I shouldn't but I could be wrong? I am using this
> toolchain file:
The toolchain files I provide are just whatever worked for me in my
situation, you need to adapt them for your situation. That one seems to
want something like
in your case, and set(CMAKE_C[XX]_COMPILER to whereever that lives.
> I have tried the debugging techniques you have kindly stated:
> - nuke any ./build dir removing the cmake cache and rebuild
> This fixed issues when building for aarch64 but not fixed now for 32 bit
> build dir. I created a new build directory from scratch.
CMake normal operation is really based around CMakeCache.txt, it tends
to be invisible and taken for granted in the case you build defaults for
with some -D from clean each time. But it is always there holding state
unless you actively kill it. You might reasonably feel you stopped
asking for some option if you run cmake again with the -D that enabled
it removed, but not so, it is still enabled in the cache.
> - study the first dozen lines of the cmake output, it should tell you
> how it feels about, eg, what compiler it is going to use.
> -- Check for working C compiler: /usr/bin/arm-linux-gnueabihf-gcc
> -- Check for working C compiler: /usr/bin/arm-linux-gnueabihf-gcc -- works
> -- Check for working CXX compiler: /usr/bin/arm-linux-gnueabihf-g++
> -- Check for working CXX compiler: /usr/bin/arm-linux-gnueabihf-g++ -- works
Yes that looks happy.
> - introduce a syntax error in the cross toolchain file
> temporarily and
> make sure that is actually getting seen
> The error is caught.
> - sudo mv your cross-compiler out of the way temporarily and make
> that causes cross-builds to fail
> Get cmake error saying it cannot build a test program.
> - sudo vim a syntax error into the build machine's
> /usr/include/openssl/ssl.h temporarily and confirm if that is really
> being picked up
> Get error: field ‘ctx’ has incomplete type
> 85 | HMAC_CTX ctx;
> But this looks like it is just because it cannot find any openssl files.
Yes it cannot judge what apis are available in your openssl accurately
if no cmake test programs probing them can build. It feels none of the
apis exist then, which is not going to be right.
Don't forget to nuke build/CMakeCache.txt after changing anything to do
More information about the Libwebsockets