libs/glibc: Backport header checks break backward compatibility

Line 20 in f27d806

patchApplySeries $<<glibc/*.diff>>

this patches break the backward compatibility to use the recipe also for glibc 2.27 (ubtuntu 18 lts):
0003-glibcextract.py-add-compile_c_snippet.diff
0004-linux-use-compile_c_snippet-to-check-linux-pidfd.h-availability.diff
0005-linux-mimic-kernel-defition-for-block_size.diff
0006-linux-use-compile_c_snippet-to-check-linux-mount.h-availability.diff
0007-linux-fix-sys-mount.h-usage-with-kernel-headers.diff

we have an overrides.yaml:

# our most common target systems including the NVIDIA AGX Jetson boards
# are an Ubuntu 18 LTS (x86_64 or aarch64) with CUDA 10.2, gcc 8.4.0 and glibc 2.27
scmOverrides:
    # gcc 8 because of cuda 10.2, that supports at least gcc upto version 8
    - match:
          url: "*gcc*12.2.0*"
      replace:
          url:
              pattern: "12.2.0"
              replacement: "8.4.0"
      set:
          digestSHA256: e30a6e52d10e1f27ed55104ad233c30bd1e99cfb5ff98ab022dc941edd1b2dd4
    # glibc 2.27 because of Ubuntu 18 LTS host and target systems
    - match:
          url: "*glibc*2.36*"
      replace:
          url:
              pattern: "2.36"
              replacement: "2.27"
      set:
          digestSHA256: 5172de54318ec0b7f2735e5a91d908afe1c9ca291fec16b5374d9faadfc1fc72

that works perfectly, but just without the new patchfiles. could we make this patches optional by a bob environment variable?

btw: this issue also exists for ubuntu 20 lts with glibc 2.31. this version will also fail with these patches!

I'm afraid making the patches optional will work on the long run. There have always been patches on glibc and gcc. Just making them optional will fail once you need a patch on your version.

I think there are two options how to solve this problem:

Maintain your own fork of basement. Just make the changes you need to deve::glibc and devel::gcc.
Create your own gcc and glib recipes. Use the existing ones as a blueprint but give them a new name. Very much like the devel::compat toolchain was created. These can be maintained in your layer/project.

I'd suggest the 2nd option. It is a bit more work but much more maintainable...

okay thanks for the reply. we'll handle this internally!