what will be impacted for compiling code in different kernel in docker?

There is, in normal situations, no exception for natively compiled codes (C, C++...).

As you wrote, programs interact with the libc, not the kernel, except very specific situations.

This libclibrary is not shared between your Ubuntu host and your Redhat container. Your container has its own libc that abstracts system calls to the kernel.

About the kernel itself, note that even if the Linux kernel internals tend to be moving, always evolving pieces of code, what is publicly exposed (the ABI, accessible to userspace applications and libc) is kept stable and compatible between releases. In rare occasions this compatibility has been broken, most of the time, not intentionally. (see this article).

So, yes, it is perfectly safe to have use a RHEL dev. environment on an Ubuntu host, and to trust the builds generated from this container.

There are no problems while the App does not directly use the last feature of a certain linux kernel.

Docker works at the lowest level intercepting only all "system calls".

In Linux 64 (x64) system calls are made with the intel / amd processor assembler instruction: SYSCALL

This SYSCALL is the one that is "intercepted" by the KERNEL of LINUX and "virtualized" with docker by internally changing the operation of the invocation.

For example, the system call "open", to open a disk file, changes the path to the file by another one where the "root" of the running docker image is located.

I do not know exactly what level of the kernel that change is made, if it is when entering "open", or if it is more internally.

For this reason, the same binary executable that works in a linux without docker, works inside a docker image, without modifying the executable at any time.

All the "virtualization" is done inside the KERNEL, which is entered for example with SYSCALL.

But beware of applications that use the latest "feature" of a kernel. Because it may not run ok, if the kernel below it does not have that "feature".

Beware of security patches at the kernel level, the kernel below may not have such a patch. In turn it is easier to install these security patches and maintain secure systems, since they are not "part" of the APPs. This is another advantage with respect to VM images.