Date: Wed, 27 Nov 2024 09:35:27 +0000 From: bugzilla-noreply@freebsd.org To: ports-bugs@FreeBSD.org Subject: [Bug 263530] devel/elfutils: Fails to build with GCC 11: ebl_syscall_abi.c:37:64: error: argument 5 of type 'int *' declared as a pointer [-Werror=array-parameter=] Message-ID: <bug-263530-7788-FbqcFiSMrR@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-263530-7788@https.bugs.freebsd.org/bugzilla/> References: <bug-263530-7788@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D263530 John Hein <jcfyecrayz@liamekaens.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |bofh@freebsd.org --- Comment #9 from John Hein <jcfyecrayz@liamekaens.com> --- (In reply to Yuri Victorovich from comment #4) "... the current version fails with gcc, even with gcc-10: https://sourceware.org/bugzilla/show_bug.cgi?id=3D29158 ..." TLDR; See [[1]] Longer explanatory read... That bug [(filed as a problem with elfutils) describes this build failure w= ith gcc11: In file included from color.c:34: /usr/local/share/gnulib/lib/argp.h:583:3: error: #error "Please include config.h first." 583 | #error "Please include config.h first." . . The underlying cause is that gcc11 (and gcc10 and gcc12) decide that despite the "-I/usr/local/include -I/usr/local/share/gnulib/lib" args to the compilation line, gcc decides to put /usr/local/share/gnulib/lib ahead of /usr/local/include in the search path. That bug was closed upstream because it was [paraphrasing] "not a elfutils problem, so WONTFIX". That seems to be true - the issue is due to a quirk = of gcc (to be fair to the upstream bug responder, it was not very clearly spel= led out in the bug thread that there are two argp.h files involved). It seems to be the case that because gcc was built with --prefix /usr/local= , it decides that the include search of /usr/local/include should be searched AF= TER the builtin search path for system directories (or put another way, it sees /usr/local/include as a system directory, so it ignores the -I/usr/local/include specified by the user because it knows that /usr/local/include will be searched as a system directory). This is expose= d if you add "-v" to the build line: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D gcc11 -D_GNU_SOURCE -DHAVE_CONFIG_H '-DLOCALEDIR=3D"/usr/local/share/locale= "' -I. -I.. -I. -I. -I../lib -I.. -I./../libelf '-std=3Dgnu99' -Wall -Wshadow '-Wformat=3D2' -Wold-style-definition -Wstrict-prototypes -Wtrampolines -Wlogical-op -Wduplicated-cond -Wnull-dereference '-Wimplicit-fallthrough= =3D5' -Werror -Wunused -Wextra '-Wstack-usage=3D262144' -fPIC '-D_FORTIFY_SOURCE= =3D3' -O2 -pipe -I/usr/local/include -I/usr/local/share/gnulib/lib -DFREEBSD_HAS_MEMP= CPY -Wno-error -Wno-format-nonliteral -Wno-null-dereference -Wno-unused-value -fstack-protector-strong -fno-strict-aliasing -MT color.o -MD -MP -MF .deps/color.Tpo -c -o color.o color.c -v . . ignoring nonexistent directory "/usr/local/lib/gcc11/gcc/x86_64-portbld-freebsd13.4/11.5.0/include-fixed" ignoring nonexistent directory "/usr/local/lib/gcc11/gcc/x86_64-portbld-freebsd13.4/11.5.0/../../../../../= x86_64-portbld-freebsd13.4/include" ignoring duplicate directory "." ignoring duplicate directory "." ignoring duplicate directory "../lib" ignoring duplicate directory ".." ignoring duplicate directory "/usr/local/include" as it is a non-system directory that duplicates a system directory #include "..." search starts here: #include <...> search starts here: . .. ./../libelf /usr/local/share/gnulib/lib /usr/local/lib/gcc11/gcc/x86_64-portbld-freebsd13.4/11.5.0/include /usr/local/include /usr/include End of search list. In file included from color.c:34: /usr/local/share/gnulib/lib/argp.h:583:3: error: #error "Please include config.h first." 583 | #error "Please include config.h first." | ^~~~~ =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Notice the message: 'ignoring duplicate directory "/usr/local/include"' Because of that quirk, gcc11 includes /usr/local/share/gnulib/lib/argp.h (f= rom the gnulib port) instead of the desired /usr/local/lib/argp.h (from the argp-standalone port)... despite the explicit ordering specified on the com= mand line. This could be construed as a bug in gcc, although it's subtle. And maybe it= is documented to behave that way intentionally - the gcc.info "Options for Directory Search" section has language that might indicate it treats /usr/local/include as a "standard system directory" which could be interpre= ted to explain this behavior as intentional. I think that adding -I/usr/local/include on the command line should be enough to tell gcc that = the user clearly wants that directory ahead of other -I directories. That gcc.= info documentation says: "However, you should not use this option [-I] to add directories that conta= in vendor-supplied system header files; use =E2=80=98-isystem=E2=80=99 for tha= t." >From that documentation, it's not clear what it will do if you DO use -I wi= th directories that gcc has been configured to understand as directories containing system header files. As it turns out, it currently removes that= -I directory as a duplicate - hardly a clear / expected implementation detail given that documentation, nor (arguably) perhaps a particularly well concei= ved one. If one "should not use" -I in that way, then the result of doing so should be spelled out clearly (and treated at run-time as a exceptional case providing a clear warning of the usage violation at run-time). clang does not alter the search path that is spelled out on the command lin= e - neither /usr/bin/clang nor /usr/local/bin/clang18. output snippet from usi= ng /usr/local/bin/clang18 shown here: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D . . ignoring duplicate directory "." ignoring duplicate directory "." ignoring duplicate directory "../lib" ignoring duplicate directory ".." #include "..." search starts here: #include <...> search starts here: . .. ./../libelf /usr/local/include /usr/local/share/gnulib/lib /usr/local/llvm18/lib/clang/18/include /usr/include End of search list. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D A workaround to allow this port to build with gcc is to use -isystem instea= d of -I [[1]]: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D gcc11 -D_GNU_SOURCE -DHAVE_CONFIG_H '-DLOCALEDIR=3D/usr/local/share/locale'= -I. -I.. -I. -I. -I../lib -I.. -I./../libelf '-std=3Dgnu99' -Wall -Wshadow '-Wformat=3D2' -Wold-style-definition -Wstrict-prototypes -Wtrampolines -Wlogical-op -Wduplicated-cond -Wnull-dereference '-Wimplicit-fallthrough= =3D5' -Werror -Wunused -Wextra '-Wstack-usage=3D262144' -fPIC '-D_FORTIFY_SOURCE= =3D3' -O2 -pipe -I/usr/local/include -I/usr/local/share/gnulib/lib -DFREEBSD_HAS_MEMP= CPY -Wno-error -Wno-format-nonliteral -Wno-null-dereference -Wno-unused-value -fstack-protector-strong -fno-strict-aliasing -MT color.o -MD -MP -MF .deps/color.Tpo -c -o color.o color.c -v . . ignoring duplicate directory "/usr/local/include" ignoring nonexistent directory "/usr/local/lib/gcc11/gcc/x86_64-portbld-freebsd13.4/11.5.0/include-fixed" ignoring nonexistent directory "/usr/local/lib/gcc11/gcc/x86_64-portbld-freebsd13.4/11.5.0/../../../../../= x86_64-portbld-freeb sd13.4/include" ignoring duplicate directory "." ignoring duplicate directory "." ignoring duplicate directory "../lib" ignoring duplicate directory ".." #include "..." search starts here: #include <...> search starts here: . .. ./../libelf /usr/local/include /usr/local/share/gnulib/lib /usr/local/lib/gcc11/gcc/x86_64-portbld-freebsd13.4/11.5.0/include /usr/include End of search list. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D This include directory search path ordering subtlety also explain why ports 2b0e78b7b9cb84 reverted the addition of USES=3Dlocalbase asserting "Somehow= this breaks the build" and added a comment saying the CFLAGS setting is "synonym= ous to USES=3Dlocalbase" (it's not quite so). Although the specific log of the failure that was observed was not included in the commit log at that time, = it appears to be the same problem including the wrong argp.h. In that case the compiler command line had include search path arguments li= ke so: '-I/usr/local/share/gnulib/lib -isystem /usr/local/include'. In this c= ase the ordering problem is more clear (and any -I vs. -isystem distinction is = not as relevant), and it fails for both clang and gcc. That committer is CC'd = here (mostly just for information than a request for any particular action... un= less desired). [[1]] So here is a patch that works for CC=3Dgcc11 or CC=3Dclang: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- a/devel/elfutils/Makefile +++ b/devel/elfutils/Makefile @@ -22,10 +22,8 @@ BUILD_DEPENDS=3D gnulib>=3D0:devel/gnulib PLIST_SUB=3D VERSION=3D${PORTVERSION} -# Although the following line is synonymous to USES=3Dlocalbase -# it breaks the build -CFLAGS+=3D -I${LOCALBASE}/include \ - -I${LOCALBASE}/share/gnulib/lib \ +CFLAGS+=3D -isystem${LOCALBASE}/include \ + -isystem${LOCALBASE}/share/gnulib/lib \ -DFREEBSD_HAS_MEMPCPY LDFLAGS+=3D ${LOCALBASE}/lib/libargp.so \ ${LOCALBASE}/lib/libintl.so =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-263530-7788-FbqcFiSMrR>