Compiling on an old system

[Oozlum]

I am looking for a bit of advice on compiling libwebsockets on an old system. As far as I can see, there should be no issue with libwebsockets itself, however I am being held back its use of CMake as the build system. For a few dependency reasons I am unable to build CMake > 2.8 on my system, but libwebsockets depends on CMake >= 3.10.

As I see it, there are two obvious routes:

1. Use a slightly newer system to generate the makefiles and try using those to compile on the older system; or
2. Try to convince libwebsockets to build with CMake 2.8.

Which of these do you think is most likely to be successful?

[lws-team]

The reason it's like that is newer cmake also "shoots stragglers", ie, some distros are shipping cmake that refuses to build projects that claim to build on < 3.5, since they removed some older cmake features / behaviours at 3.5. Hence we are forced to backstop at 3.5 so it will build normally for people on up-to-date systems.

The best way is build modern cmake on your older distro, I have done this before from cmake git, and although it's not simple it did work, at least under my conditions. Then you can remove your packaged cmake and install your new one and it will just work. You can also consider getting a source package (srpm or source deb or whatever) from a later version of the same distro and rebuilding it locally as a package, against your old deps, and then upgrading to that.

[Oozlum]

So, to clarify, are you saying that libwebsockets should build with CMake >= 3.5, rather than >= 3.10 specified in the sources? If so, then I think I'm on to a winner, as I have just managed to build CMake 3.6.0.

I can't build anything much more recent due to system limitations:
CMake >= 3.8 => libuv => atomics which are unsupported on my system.
CMake >= 3.10 => c++11 => g++ >= 4.8 => glibc more recent than my system.

[lws-team]

lws itself was using the older 2.xx cmake for a long while, it was cmake itself that pushed the lower limit to 3.5. If it's 3.10 now, that will also be a problem created by later cmake deprecating anything below 3.10 because they removed the older apis.

It can probably build with 3.5 but the problem is there's no way to override the CMakeLists.txt project info with 3.10 externally. And it's in all the example projects... you could do a mega-sed but the only way through it that won't make trouble is build a modern cmake > 3.10.

[Oozlum]

Thanks. A mega-sed has allowed the CMake stage to complete successfully. I'm now getting some compiler errors, but that should hopefully be much easier to resolve.

[Oozlum]

Is libwebsockets 4.4-stable known to compile against mbedtls 3.6.5? I'm getting the following error:
libwebsockets-git/lib/tls/mbedtls/lws-genhash.c:279: error: implicit declaration of function 'mbedtls_md_init_ctx'

[lws-team]

Yeah it shouldn't have any trouble AFAIK.

Deprecated:
Superseded by [mbedtls_md_setup()](https://mbed-ce.github.io/mbed-os/
group__mbedtls__md__module.html#ga1b858111212997b90bd7d2c71010a7ec) in 2.0.0

It seems to be choosing the older api? The test is like this in current lws

#if defined(LWS_HAVE_mbedtls_md_setup) || \
    (defined(MBEDTLS_VERSION_NUMBER) && MBEDTLS_VERSION_NUMBER >= 0x03000000)
        if (mbedtls_md_setup(&ctx->ctx, ctx->hmac, 1))
                return -1;
#else
        if (mbedtls_md_init_ctx(&ctx->ctx, ctx->hmac))
                return -1;
#endif

You might want to look through the log cmake keeps of the test builds it does to find out what apis are available to see why it feels LWS_HAVE_mbedtls_md_setup isn't there? Any failure of the test build will mark is as unavailable, eg, unexprected library needed.

[Oozlum]

Thanks for the pointer, it is nothing to do with libwebsockets. The mbedtls build failed to link against a required library, so your test indirectly resulted in an undefined reference during the link step.

[Oozlum]

I have finally managed to build a minimal libwebsockets library, and in doing so encountered a few issues:

1. numerous type conversion warnings which forced me to disable Werror;
2. a single instance of a variable instantiated inside a 'for' loop, which requires C99; and
3. lib/plat/unix/unix-sockets.c includes both <linux/ipv6.h> (LWS_HAVE_LINUX_IPV6_H) and <netinet/ip.h>, which causes an error because in6_addr is defined in both.

Given the age of my system and that these clearly don't affect newer systems I suspect you won't be too interested in resolving them, but if you are then I'm happy to help.

[lws-team]

C99

How old is this system? 1999 was 27 years ago. We now use c99 array initializers as well, but I guess your toolchain supports it.

It builds on many different modern systems with -Wall -Werror completely cleanly. You can externally disable -Werror via an existing cmake option so I think it's OK like this.

I guess we could add a cmake option to snip one or the other of the includes that clash on your system, if you would like to send a patch.

[Oozlum]

It's based on Debian Lenny, so 2012. The compiler supports c99, but for some reason objects to that one specific use unless '-std=c99' is passed explicity.

The type conversions I agree are a bit of a non-issue, given CMAKE_DISABLE_WERROR exists.

I'll send patches / pull requests for the very few trivial issues; if you're happy to except them then fine.

I really don't know what to do about the IPV6 includes though. To the best of my understanding, code is not supposed to include both linux and C library headers at the same time, but clearly there was a very good reason for doing so at the time. I'm not sure what the conditions would be for deciding one way or the other, or even which one is appropriate for my system.

[lws-team]

For the includes, presumably you did "something", a local edit, to make it build under your circumstances, I'm just suggesting adding a cmake option that causes your "something" to happen that your system needs.

Really old distros are quite difficult to keep breathing life into, eg, their trusted CAs are mostly expired, they don't know about now-historical crises like the Great-Let's-Encrypt-CA-change and so on. At least that's why I don't target making lws work on them.

[Oozlum]

Sure, I simply commented out that include. But a) I compiled with LWS_WITH_IPV6=0; and b) my goal was simply to get to a successful compilation. I'm not confident that successful compilation is proof of correctness, although in the case of a simple header inclusion that may be the case.

I haven't yet tried compiling with LWS_WITH_IPV6=1, so perhaps I should do that.

[Oozlum]

I've tested with IPV6 and everything seems to be fine, so I've added that to my pull request.