Error when building with GCC 14

[tuliom]

When GCC 14 is used to build libnxz, the following error is shown:

nx_gzlib.c: In function ‘__gzopen’:
nx_gzlib.c:195:36: error: assignment to ‘int’ from ‘void *’ makes integer from pointer without a cast [-Wint-conversion]
  195 |                                 err=Z_NULL;
      |                                    ^
make[2]: *** [Makefile:527: nx_gzlib.lo] Error 1
make[2]: *** Waiting for unfinished jobs....

[sachinmonga64]

@tuliom

Tried building libnxz with gcc-14 and it got compiled successfully.

]$ /opt/gcc-nightly/trunk/bin/gcc --version

gcc (GCC) 14.0.1 20240124 (experimental) [remotes/origin/HEAD r14-8379-g7f7d9c525c]
Copyright (C) 2024 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

]$ ./configure CC="/opt/gcc-nightly/trunk/bin/gcc" && make > makelog.log

]$ grep -inr nx_gzlib makelog.log | grep gcc

1060:/bin/sh ../libtool  --tag=CC   --mode=compile /opt/gcc-nightly/trunk/bin/gcc -DHAVE_CONFIG_H -I. -I..  -I../inc_nx -DZLIB_PATH=\"libz.so\"   -O3 -Wall -Werror -g -mcpu=power9 -MT nx_gzlib.lo -MD -MP -MF $depbase.Tpo -c -o nx_gzlib.lo nx_gzlib.c &&\
1062:libtool: compile:  /opt/gcc-nightly/trunk/bin/gcc -DHAVE_CONFIG_H -I. -I.. -I../inc_nx -DZLIB_PATH=\"libz.so\" -O3 -Wall -Werror -g -mcpu=power9 -MT nx_gzlib.lo -MD -MP -MF .deps/nx_gzlib.Tpo -c nx_gzlib.c  -fPIC -DPIC -o .libs/nx_gzlib.o

1063:libtool: compile:  /opt/gcc-nightly/trunk/bin/gcc -DHAVE_CONFIG_H -I. -I.. -I../inc_nx -DZLIB_PATH=\"libz.so\" -O3 -Wall -Werror -g -mcpu=power9 -MT nx_gzlib.lo -MD -MP -MF .deps/nx_gzlib.Tpo -c nx_gzlib.c -o nx_gzlib.o >/dev/null 2>&1

1089:/bin/sh ../libtool  --tag=CC   --mode=link /opt/gcc-nightly/trunk/bin/gcc  -O3 -Wall -Werror -g -mcpu=power9 -version-info 0:64:0 -Wl,--version-script=./Versions  -o libnxz.la -rpath /usr/local/lib crc32_ppc.lo crc32_power.lo gzip_vas.lo nx_map.lo nx_adler32.lo nx_compress.lo nx_crc.lo nx_deflate.lo nx_dht.lo nx_dhtgen.lo nx_dht_builtin.lo nx_gzlib.lo nx_inflate.lo nx_uncompr.lo nx_utils.lo nx_zlib.lo sw_zlib.lo -lpthread -ldl

1090:libtool: link: /opt/gcc-nightly/trunk/bin/gcc -shared  -fPIC -DPIC  .libs/crc32_ppc.o .libs/crc32_power.o .libs/gzip_vas.o .libs/nx_map.o .libs/nx_adler32.o .libs/nx_compress.o .libs/nx_crc.o .libs/nx_deflate.o .libs/nx_dht.o .libs/nx_dhtgen.o .libs/nx_dht_builtin.o .libs/nx_gzlib.o .libs/nx_inflate.o .libs/nx_uncompr.o .libs/nx_utils.o .libs/nx_zlib.o .libs/sw_zlib.o   -lpthread -ldl  -O3 -g -mcpu=power9 -Wl,--version-script=./Versions   -Wl,-soname -Wl,libnxz.so.0 -o .libs/libnxz.so.0.0.64

]$ find . -iname nx_gzlib.*

./lib/nx_gzlib.c
./lib/.deps/nx_gzlib.Plo
./lib/.libs/nx_gzlib.o
./lib/nx_gzlib.o
./lib/nx_gzlib.lo

Let me know if I am missing anything here.

[tuliom]

Let's try with a more specific command:

/opt/gcc-nightly/trunk/bin/gcc -DHAVE_CONFIG_H -I. -Ilib -Iinc_nx -DZLIB_PATH=\"libz.so\" -O3 -Wall -Werror -g -mcpu=power9 -c lib/nx_gzlib.c  -fPIC -DPIC -o .libs/nx_gzlib.o

What do you get when you run that?

For the record, we're seeing this when building libnxz on Fedora Rawhide (aka. what will become Fedora 40).

This environment can be recreated with podman:

podman run -it --rm fedora:rawhide bash

[tuliom]

Let's try with a more specific command:

/opt/gcc-nightly/trunk/bin/gcc -DHAVE_CONFIG_H -I. -Ilib -Iinc_nx -DZLIB_PATH=\"libz.so\" -O3 -Wall -Werror -g -mcpu=power9 -c lib/nx_gzlib.c  -fPIC -DPIC -o .libs/nx_gzlib.o

@sachinmonga64 If the previous command doesn't show the error, what happens when you add -Wint-conversion?

[sachinmonga64]

@tuliom

Both command versions are working fine.

]$ /opt/gcc-nightly/trunk/bin/gcc -DHAVE_CONFIG_H -I. -Ilib -Iinc_nx -DZLIB_PATH=\"libz.so\" -O3 -Wall -Werror -g -mcpu=power9 -c lib/nx_gzlib.c -fPIC -DPIC -o ./lib/nx_gzlib.o

]$ /opt/gcc-nightly/trunk/bin/gcc -DHAVE_CONFIG_H -I. -Ilib -Iinc_nx -DZLIB_PATH=\"libz.so\" -O3 -Wall -Werror -g -mcpu=power9 -c lib/nx_gzlib.c -Wint-conversion -fPIC -DPIC -o ./lib/nx_gzlib.o

Seems like podman specific issue ???

[tuliom]

Seems like podman specific issue ???

@sachinmonga64 Definitely not. The compiler is pointing pointing to an error correctly.

[tuliom]

I see what is happening: this only happens when using GCC 14 and zlib-ng compat headers because it defines Z_NULL as NULL instead of 0.

[sachinmonga64]

Not checked with zlib-ng . Do you want me to verify ? Also , what is the solution ?

[tuliom]

I have a suggested solution in PR #209 .

[fweimer-rh]

I see what is happening: this only happens when using GCC 14 and zlib-ng compat headers because it defines Z_NULL as NULL instead of 0.

@tuliom Should this be fixed in zlib-ng?

[tuliom]

@tuliom Should this be fixed in zlib-ng?

@fweimer-rh That's a good question. Regardless, we do need the fix in PR #209. In order to answer if zlib-ng needs to be fixed too, we first need to answer if using Z_NULL as an integer is valid. All the references I found pointed out that Z_NULL is supposed to be used only as a pointer, e.g. https://refspecs.linuxbase.org/LSB_3.0.0/LSB-Core-generic/LSB-Core-generic/zlib-gzopen-1.html With this interpretation, I don't think zlib-ng needs to be fixed. I'm open to change that interpretation though.

[tuliom]

Fixed in the devel branch.