Open dmik opened 5 years ago
Actually, I don't like the idea of hardcoding __LIBCN__
in to gcc built-ins. We should find a solution to pick it up from LIBC Next somehow to avoid rebuilding GCC each time a LIBCn patch level changes. See https://github.com/bitwiseworks/libc/issues/29.
Note that I've added __LIBCN__
and friends in LIBCn itself (see https://github.com/bitwiseworks/libc/issues/29) so they shouldn't be added here.
However, I think that we should eventuall remove __KLIBC__
and friends (including __INNOTEK_LIBC__
) from GCC built-ins. They are clearly foreign here. Yes, this may break some sources that don't include any standard C header but rely on either of these macros but I'm not sure a real case like that exists.
I will leave this open until we decide.
There is a bunch of built-in defines related to kLIBC:
https://github.com/psmedley/gcc/blob/21e0dd64d12d316004faedd38125e06872dd937a/gcc/config/i386/emx.h#L394
Given that we rebrand kLIBC to LIBC Next after forking (see https://github.com/bitwiseworks/libc/issues/17 for more info), we need to add a respective
__LIBCN__
define here.And we should also fix
__KLIBC_PATCHLEVEL__
and__KLIBC_VERSION__
to match the point where we forked (i.e. kLIBC 0.6.6).