In the old version of glibc and O2 is enabled, replacing the strncmp argument with a macro will cause the compilation to fail about neovim

[hardboydu]

Maybe the minimum glibc version has been increased. That would in that case be a documentation issue and this would be a wontfix. I'll need to check.

TODO: if this turns out to be the case, look into adding a minimum glibc check in build.yml if it's simple to do so.

CentOS 7.x is so widely used as a production system that I don't think it's time to give up on supporting it

[moonstruckmoth]

I'm facing the same issue and I've tracked down the commit from where it started failing to compile.

The commit is as below

commit c37695a (HEAD)
Author: James [email protected]
Date: Tue Jun 11 22:40:24 2024 +0700

refactor: use S_LEN(s) instead of s, n (#29219)

[dundargoc]

Which version of glibc are you using?

[hardboydu]

Which version of glibc are you using?

GNU C Library (GNU libc) stable release version 2.17

[dundargoc]

Maybe the minimum glibc version has been increased. That would in that case be a documentation issue and this would be a wontfix. I'll need to check.

TODO: if this turns out to be the case, look into adding a minimum glibc check in build.yml if it's simple to do so.

[clason]

CentOS 7.x is so widely used as a production system that I don't think it's time to give up on supporting it

So is Neovim 0.9. If you run a legacy version of an OS, you should expect to have to run legacy versions of applications as well. We don't drop support at a whim; we try to keep things running on as many platforms as possible. But at the same time, we will not refrain from making necessary or useful changes just for the sake of legacy platforms. (Again, you can keep using older versions; it's not like they are removed from the internet...)

In this specific case, we are talking about a nightly build for a version that will be released in months -- long after CentOS 7's end of life (June 30, 2024).

[dundargoc]

This discussion is premature. I have no idea yet if the problem is in fact that minimum glibc has been increased. I probably shouldn't have brought up the possibility of "wontfix" before confirming it.

@hardboydu can you bisect the commit where building breaks for you? make distclean may help here in case the build breaks for unrelated reasons.

[dundargoc]

@IAKOBVS

[IAKOBVS]

@IAKOBVS

S_LEN macro doesn't work when passed as an argument to another macro. That's why I didn't use it for the STRNICMP macros, only functions.

[clason]

Yes, obviously. Can you fix this so it works on all supported platforms, or should we revert that commit?

[IAKOBVS]

Yes, obviously. Can you fix this so it works on all supported platforms, or should we revert that commit?

Just revert it.

[gpanders]

Is this something we can test for in CI? Otherwise how we will know if any use of S_LEN is safe? (Unless we make a rule: "never use S_LEN in stdlib functions because those could secretly be macros").

[clason]

Not without containers. (But I believe this sort of "macro wrappers for gcc" in glibc can be researched; It will take some effort, though.)

[dundargoc]

Is this something we can test for in CI? Otherwise how we will know if any use of S_LEN is safe? (Unless we make a rule: "never use S_LEN in stdlib functions because those could secretly be macros").

I don't see how we could. Even if we start testing centos specifically it won't account for other distros. We could start testing a slew of popular distros (centos, debian, fedora, arch, manjaro, etc etc) but that is going to be expensive CI-wise.