背景

早先社区报过 opentelemetry-cpp 在GCC 14中编译不通过的问题。最近我也是先升级我们项目组的工具链，主要也是把GCC升级到GCC 14，这时候发现有些第三方工具构建失败。 这里记录一下以防后续其他人碰到参考。

分析

我们在使用新版本GCC 14编译zsh的时候，报 boolcodes 和定义冲突。

分析下来发现是在 ./configure 阶段， boolcodes 这个接口的时候不通过。

从 ./configure 里提取出来的，测试代码如下:

#include <curses.h>
#include <term.h>
int
main (void)
{
char **test = boolcodes; puts(*test);
  ;
  return 0;
}

编译命令: gcc -o conftest -I/opt/tools/include -I/opt/gcc-14/internal-packages/include -L/opt/tools/lib64 -L/opt/tools/lib -L/opt/gcc-14/lib64 -L/opt/gcc-14/lib -lncursesw -ltinfow test-source.c -lpcre -liconv -lcap -ldl -lrt -lm -lc

编译输出:

test-source.c: In function ‘main’:
test-source.c:6:15: error: initialization of ‘char **’ from incompatible pointer type ‘const char * const*’ [-Wincompatible-pointer-types]
    6 | char **test = boolcodes; puts(*test);

虽然说这里 zsh 的代码也有问题，但是可以看到。我们并没有加 -Werror 或者 -Werror=incompatible-pointer-types 它也报错了。 即便我们加了 -Wno-error （即用: gcc -o conftest -I/opt/tools/include -I/opt/gcc-14/internal-packages/include -L/opt/tools/lib64 -L/opt/tools/lib -L/opt/gcc-14/lib64 -L/opt/gcc-14/lib -lncursesw -ltinfow test-source.c -lpcre -liconv -lcap -ldl -lrt -lm -lc -Wno-error ）。任然会报这个错误。

只有显式加 -Wno-error=incompatible-pointer-types 之后，输出才会变为:

test-source.c: In function ‘main’:
test-source.c:6:15: warning: initialization of ‘char **’ from incompatible pointer type ‘const char * const*’ [-Wincompatible-pointer-types]
    6 | char **test = boolcodes; puts(*test);
      |               ^~~~~~~~~

另一个阻塞问题

编译玩以后，我们会发现zsh启动的时候卡在了 waitforpid 调用上，我们看这个函数的代码:

/**/
int
waitforpid(pid_t pid, int wait_cmd)
{
    int first = 1, q = queue_signal_level();

    /* child_block() around this loop in case #ifndef WNOHANG */
    dont_queue_signals();
    child_block();		/* unblocked in signal_suspend() */
    queue_traps(wait_cmd);

    /* This function should never be called with a pid that is not a
     * child of the current shell.  Consequently, if kill(0, pid)
     * fails here with ESRCH, the child has already been reaped.  In
     * the loop body, we expect this to happen in signal_suspend()
     * via zhandler(), after which this test terminates the loop.
     */
    while (!errflag && (kill(pid, 0) >= 0 || errno != ESRCH)) {
	if (first)
	    first = 0;
	else if (!wait_cmd)
	    kill(pid, SIGCONT);

	last_signal = -1;
	signal_suspend(SIGCHLD, wait_cmd);
	if (last_signal != SIGCHLD && wait_cmd && last_signal >= 0 &&
	    (sigtrapped[last_signal] & ZSIG_TRAPPED)) {
	    /* wait command interrupted, but no error: return */
	    restore_queue_signals(q);
	    return 128 + last_signal;
	}
	child_block();
    }
    unqueue_traps();
    child_unblock();
    restore_queue_signals(q);

    return 0;
}

乍看是没什么问题的，深入到 config.log 我们会发现它在测试 ESRCH 的时候失败了，然后再失败的时候会把 ESRCH 定义成 EINVAL 。 测试 ESRCH 失败的原因其实和上面的问题一样，也是仅有 -Wimplicit-int 的时候触发了 error 。所以解决方法也是加 -Wno-error=implicit-int 。

解决

最后，我给工具链脚本加了个编译选项检测来解决这类问题。

# Patch for gcc 14
for TEST_CFLAG in "-Wno-error=incompatible-pointer-types" "-Wno-error=implicit-int" "-Wno-error"; do
  echo "Test CFLAG: $TEST_CFLAG"
  (gcc $TEST_CFLAG -x c - -o /dev/null <<<'int main() { return 0; }' && echo "Test CFLAG: $TEST_CFLAG success" && ALL_CFLAGS="$ALL_CFLAGS $TEST_CFLAG") || echo "Test CFLAG: $TEST_CFLAG failed"
done

也不排除后面更新构建系统 cmake-toolset 的时候会发现其他外部组件有相似问题，到时候再打Patch吧。欢迎有兴趣的小伙伴互相交流研究。