EXTRA_CFLAGS=-m32 or -m64 etc fails

[rdebath]

The makefile has EXTRA_CFLAGS for flags to add to the C compile but EXTRA_CFLAGS=-m32 or -m64 etc fails because it's not applied to the link phase too.

[UnknownShadow200]

Not sure if it makes sense to have CFLAGS always apply in the linking phase too.

There is EXTRA_LIBS, I suppose I could rename that to EXTRA_LDFLAGS

[rdebath]

NB: I should mention I'm compiling for linux.

Okay, that'll probably be fine for any modern linker (eg: GNU and Clang) as they are mostly insensitive to the argument order. However, the normal define for this for gmake is called TARGET_ARCH. Using this flag could also trigger a distinct build directory, like using a different compiler (eg an actual cross compiler) should.

Oh and the final executable can't find OpnSSL's libcrypto despite it being installed. (Actually four times, x64, x86, aarch64 and arm), hmm, actually, I think it might be just complaining that machine is Debian-11, maybe it should keep quiet unless there's a real problem.

I don't see any option to shared link it directly (-lcrypto) like all the other libraries.

Lastly it seems a little odd that you seem to use both BearSSL and OpenSSL (libcrypto), especially as BearSSL doesn't look too well supported, with no actual release for seven years despite a few bugs.

[UnknownShadow200]

Okay, that'll probably be fine for any modern linker (eg: GNU and Clang) as they are mostly insensitive to the argument order.

I can add both EXTRA_LDFLAGS and EXTRA_LIBS in the correct argument locations, if that would work better.

However, the normal define for this for gmake is called TARGET_ARCH. Using this flag could also trigger a distinct build directory, like using a different compiler (eg an actual cross compiler) should.

I hadn't really thought much about using the Makefile for cross compilation, given that github workflows are used for cross compiling. I suppose I can look at automatically adding TARGET_ARCH to BUILD_DIR.

Oh and the final executable can't find OpnSSL's libcrypto despite it being installed. (Actually four times, x64, x86, aarch64 and arm), hmm, actually, I think it might be just complaining that machine is Debian-11, maybe it should keep quiet unless there's a real problem.

If it cannot find libcrypto.so.3 nor libcrypto.so, then it is a problem.

I don't see any option to shared link it directly (-lcrypto) like all the other libraries.

It is always dynamically loaded (like OpenAL), so that ClassiCube can still function even if the library is missing from the end user's machine. There isn't an option of linking it directly.

Lastly it seems a little odd that you seem to use both BearSSL and OpenSSL (libcrypto),

BearSSL is used to provide the TLS 1.0 - 1.2 support on all platforms which support SSL. I did this because running on devices either not supporting TLS 1.2 or missing some necessary required SSL root certificates has probably been the most raised issue over the years. The only downside is that the root certificates have to be hardcoded into the ClassiCube binary, and so only a few root certificates are hardcoded. So if the provided SSL certificate chain isn't trusted by any of the hardcoded root certifcates, ClassiCube will try falling back to an operating system specific API for verifying whether the SSL certificate chain is trusted - which is OpenSSL on Linux.

especially as BearSSL doesn't look too well supported, with no actual release for seven years despite a few bugs.

I don't see a lack of release as particularly concerning, given that its goal was to be a simple TLS 1.0 - 1.2 library, and that was achieved. I did copy the BearSSL code from the latest commit from 2024 though. Are there unresolved bugs though?