gphoto / libgphoto2

The libgphoto2 camera access and control library.
GNU Lesser General Public License v2.1
989 stars 316 forks source link

With gcc 14 around the corner, we really need to fix at least some compiler warnings #959

Open ndim opened 5 months ago

ndim commented 5 months ago

BTW looks lile with latest glibc and gcc 14.x test suite build fails because it cannot be build wit -D_FORTIFY_SOURCE=3 which turns -Wimplicit-int and -Wimplicit-function-declaration into errors

/usr/bin/g++ -DHAVE_CONFIG_H -I. -I..  -I../libgphoto2_port -I..  -std=c++98 -pedantic -Wall -Wextra -Werror  -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -O2 -g -grecord-gcc-switches -pipe -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -fdata-sections -ffunction-sections -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -flto=auto -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS -Wall -Werror=format-security -c -o test_pedantic_cxx98-test-pedantic-compilation.o `test -f 'test-pedantic-compilation.cxx' || echo './'`test-pedantic-compilation.cxx
test-pedantic-compilation.cxx: error: -Wno-implicit-int detected - is this intentional ? [-Werror]
test-pedantic-compilation.cxx: error: -Wno-implicit-function-declaration detected - is this intentional ? [-Werror]
cc1plus: all warnings being treated as errors
make[2]: *** [Makefile:1308: test_pedantic_cxx98-test-pedantic-compilation.o] Error 1

Originally posted by @kloczek in https://github.com/gphoto/libgphoto2/issues/773#issuecomment-1917823555

ndim commented 5 months ago

gcc 14 is coming, and will enable some warnings as errors by default.

The mass rebuilds for the upcoming Fedora 40 have exposed some of that already, e.g. https://bugzilla.redhat.com/show_bug.cgi?id=2261324 or https://koji.fedoraproject.org/koji/taskinfo?taskID=112078167 (https://kojipkgs.fedoraproject.org//work/tasks/8282/112078282/build.log).

We need a systematic effort to eliminate compiler warnings, both relatively quickly to keep libgphoto2 building with gcc 14, and then more completely for our own sanity and peace of mind.

Ideally, we will eventually build with zero warnings, but that will take a lot of effort.

I recently tried looking into some integer warnings, but we have a lot of them and many are systematic issues, not just the occasional forgotten cast from ssize_t to size_t having ruled out the < 0 case.

Things like comparing int members in one PTP related struct with unsigned int members of the same name in a different struct with the same member names. No idea what the PTP specs actually says about the signedness of those values, but what I could find with those struct member names in some PTP standard documents was partially 4 byte and partially 2 byte values, both of which are represented by int and unsigned int in our codebase.

Anyway, such things should be solvable by properly using uint16_t and uint32_t where applicable. I would hope this is only libgphoto2/libgphoto2_port internal stuff and does not affect the external APIs.

msmeissn commented 5 months ago

currently openSUSE tumbleweed does not have gcc14 yet, so I can take it up once it gets it.

ndim commented 5 months ago

I have set up a VM with Fedora 40 for a quick check, but I could not reproduce the original post.

I want to merge the two configure scripts into one first, and only then start fixing the warnings. That should save on build times.

kloczek commented 5 months ago

Actually reported issue is result of use latest devel glibc with -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 in CFLAGS which changes those warnings into errors.

Instead wasting time on create Fedora build env better would be just sort out those warnings.

ndim commented 5 months ago

Not sure why trying to reproduce a reported problem would a waste of time...

Anyway, I could not reproduce the issue using the Fedora 40 packages

gcc-14.0.1-0.4.fc40.x86_64
glibc-2.38.9000-39.fc40.x86_64

running

autoreconf -vis .
./configure --with-camlibs=everything
make -j$(nproc) CFLAGS="-O2 -g -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3" CXXFLAGS="-O2 -g -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3" all check

on libgphoto2 commit 846ae9f2199eb8bcbcb6d8bfe47fc961a033519a.

What exactly is "[the] latest devel glibc"? What libgphoto2 commit are you building? Using what commands?

kloczek commented 5 months ago

What exactly is "[the] latest devel glibc"? What libgphoto2 commit are you building? Using what commands?

Snapshot of the glibc which is now used in fedora rawhide.

ndim commented 4 months ago

Another thing, this time building for i686. Quoting https://src.fedoraproject.org/rpms/libgphoto2/pull-request/5:

ptp2/chdk.c:1186:41: error: passing argument 3 of 'jpeg_mem_dest' from incompatible pointer type [-Wincompatible-pointer-types]
/usr/include/jpeglib.h:922:43: note: expected 'long unsigned int *' but argument is of type 'uint64_t *' {aka 'long long unsigned int *'}
yselkowitz commented 4 months ago

Another thing, this time building for i686. Quoting https://src.fedoraproject.org/rpms/libgphoto2/pull-request/5:

ptp2/chdk.c:1186:41: error: passing argument 3 of 'jpeg_mem_dest' from incompatible pointer type [-Wincompatible-pointer-types]
/usr/include/jpeglib.h:922:43: note: expected 'long unsigned int *' but argument is of type 'uint64_t *' {aka 'long long unsigned int *'}

This is already fixed; see #941

msmeissn commented 4 months ago

its not the -D_FORTIFY_SOURCE=3 usually turning on errors, but try

-fhardened or so which is new with gcc14

fweimer-rh commented 4 months ago

This:

test-pedantic-compilation.cxx: error: -Wno-implicit-int detected - is this intentional ? [-Werror]
test-pedantic-compilation.cxx: error: -Wno-implicit-function-declaration detected - is this intentional ? [-Werror]

is a downstream-only thing in Fedora, related to its use of annobin. If this reproduces in Fedora rawhide, it should be raised as an annobin bug.

kloczek commented 4 months ago

its not the -D_FORTIFY_SOURCE=3 usually turning on errors, but try

-fhardened or so which is new with gcc14

I'm not using such option.

kloczek commented 4 months ago

is a downstream-only thing in Fedora, related to its use of annobin. If this reproduces in Fedora rawhide, it should be raised as an annobin bug.

Why not tolerating some exact warning is kind of bug? 🤔