Use `-std=gnu11` instead of `-std=c11` on Linux

[4og]

What

Baselibs module is going to depend on OpenSSL from BCR. The BCR-provided OpenSSL relies on GNU extensions for C11, and therefore requires compilation with -std=gnu11 on Linux.

At the moment, the Linux cc_toolchain enforces -std=c11, which causes the build to fail.
The task is to investigate the feasibility and impact of switching the Linux toolchain to use -std=gnu11 instead.

Acceptance Criteria (DoD)

How

Change here to gnu11

bazel_cpp_toolchains/templates/linux/cc_toolchain_flags.bzl.template

Lines 66 to 69 in 1f1b1d1

	# Default compile flags for C language when no specific build type is selected.
	DEFAULT_C_COMPILE_FLAGS = get_flag_group([
	"-std=c11",
	])

[4og]

@odra, @opajonk, @nradakovic, what do you think about this?

[AlexanderLanin]

Can you please explain why OpenSSL is used and what exactly is missing with c11? As we really hesitate to add a gnu dependency to S-CORE.
E.g. how will this work with other compilers, how will this be restricted to communication etc.

And we'd like to move this through architecture round as well.

[nradakovic]

I actually have one more question. As far as I can see, --std=c11, at least that's what I'm reading from docs should be enough to build OpenSSL. I could be wrong, just I cannot find info with statement GNU extentions are needed to build OpenSSL. Can you maybe point ( I'm pretty sure architecture will want to know ) where is this set as build requirement in OpenSSL? I'm not expert in OpenSSL, so I just want to make sure we have all info at hand before we decide with flag switch.

[nradakovic]

And I'm now going to answer to my question. :)
Verified:
there is real source-level dependence on GNU extensions in the OpenSSL code path under providers/implementations/rands/drbg_ctr.c where openssl calls GETU32 and PUTU32. These macros in openssl go through BSWAP4, whose GNU paths use ({ ... }) and asm.

This basicly gives us why build of this module fails in a strict ISO C mode. On question why baselibs + communication ( I guess ) are using OpenSSL, someone else will need to reply.

[4og]

There will be a new hashing library in baselibs, primarily intended for use in https://github.com/eclipse-score/config_management. This library depends on OpenSSL.

I don't see a problem with enabling gnu11 on Linux (though not necessarily on QNX). I'm fairly sure that any vendor aiming to certify a Linux distribution should have a qualified compiler that supports the GNU dialect. Otherwise, I don't know how this all is expected to work, given that even the kernel itself must be built with -std=gnu11:
https://www.kernel.org/doc/html/latest/process/programming-language.html

[clemens-k]

I just tried to build OpenSSL 3.5.5 (LTS) from source (not from bcr):

• one important GNU extension used is "asm" for inline assembly. Using the hash define -Dasm=__asm__ solves that problem and allowed -std=c11 setting (see "Notes" in https://en.cppreference.com/w/c/language/asm.html)
• timezone and strdup() are also causing compiler errors, but by adding -D_GNU_SOURCE (at least on ubuntu 24.04 with gcc 13.x) we can declare that the source code uses GNU extensions

Can you try those compiler options?

-std=c11 -Dasm=__asm__ -D_GNU_SOURCE