On Sat, Oct 23, 2021 at 12:01 AM <[email protected]> wrote:
> Date: Fri, 22 Oct 2021 05:20:57 +0000 > From: HAGIO KAZUHITO(?????) <[email protected]> > To: Alexander Egorenkov <[email protected]> > Cc: "Discussion list for crash utility usage, maintenance and > development" <[email protected]> > Subject: Re: [Crash-utility] eppic extension doesn't build with recent > master > Message-ID: > < > tyypr01mb677798cf5c8af09969686ce9dd...@tyypr01mb6777.jpnprd01.prod.outlook.com > > > > Content-Type: text/plain; charset="iso-2022-jp" > > -----Original Message----- > > Hello, > > > > i'm trying to build the recent master branch of the crash utility and > > not able to build eppic extension. > > Hi Alex, > > Thanks for the report, it's the same on my machine, I forgot this.. > Seems that it doesn't support gdb-10.2 currently. > > I've cc'd Luc, who is its maintainer. Any information about this? > > The following patch describes the reason for this change in gdb. It includes both C and C++ header files in a file simultaneously, which may trigger the following compilation issues. ... In file included from ../gdb-10.2/gdb/defs.h:28, from eppic/applications/crash/eppic.c:22: ../gdb-10.2/gdbsupport/common-defs.h:90:10: fatal error: cstdlib: No such file or directory #include <cstdlib> ^~~~~~~~~ compilation terminated. ... But on the other hand, the eppic also needs to embrace these changes, the eppic code included some header files, which did not exist in gdb-10.2, accordingly it should remove(or change) these header files such as "gdb_string.h" and "gdb_stat.h". It looks like an intertwined issue, just providing a clue for this issue. Subject: [PATCH] gdbsupport: include cstdlib in common-defs.h In PR 25731 [1], the following build failure was reported: ../../binutils-gdb/gdb/gdbtypes.c:1254:10: error: no member named 'abs' in namespace 'std'; did you mean simply 'abs'? = ((std::abs (stride) * element_count) + 7) / 8; ^~~~~~~~ abs /usr/include/stdlib.h:129:6: note: 'abs' declared here int abs(int) __pure2; ^ The original report was using: $ gcc -v Apple LLVM version 8.0.0 (clang-800.0.42.1) Target: x86_64-apple-darwin15.6.0 Note that I was _not_ able to reproduce using: $ g++ --version Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/c++/4.2.1 Apple clang version 11.0.0 (clang-1100.0.33.17) Target: x86_64-apple-darwin19.3.0 The proposed fix is to include <cstdlib> in addition to <stdlib.h>. Here's an excerpt of [2] relevant to this problem: These headers [speaking of the .h form] are allowed to also declare the same names in the std namespace, and the corresponding cxxx headers are allowed to also declare the same names in the global namespace: including <cstdlib> definitely provides std::malloc and may also provide ::malloc. Including <stdlib.h> definitely provides ::malloc and may also provide std::malloc Since we use std::abs, we should not assume that our include of stdlib.h declares an `abs` function in the `std` namespace. If we replace the include of stdlib.h with cstdlib, then we fall in the opposite situation. A standard C++ library may decide to only put the declarations in the std namespace, requiring us to prefix all standard functions with `std::`. I'm not against that, but for the moment I think the safest way forward is to just include both. Note that I don't know what effect this patch can have on any stdlib.h fix provided by gnulib. [1] https://sourceware.org/bugzilla/show_bug.cgi?id=25731 [2] https://en.cppreference.com/w/cpp/header#C_compatibility_headers gdbsupport/ChangeLog: * common-defs.h: Include cstdlib.h. diff --git a/gdbsupport/common-defs.h b/gdbsupport/common-defs.h index e42d2b80c045..d3f5eafa4555 100644 --- a/gdbsupport/common-defs.h +++ b/gdbsupport/common-defs.h @@ -84,7 +84,12 @@ #include <stdarg.h> #include <stdio.h> + +/* Include both cstdlib and stdlib.h to ensure we have standard functions + defined both in the std:: namespace and in the global namespace. */ +#include <cstdlib> #include <stdlib.h> + #include <stddef.h> #include <stdint.h> #include <string.h> -- 2.20.1 Thanks, > Kazu > > > > > > The build failure on x86_64 Fedora 34 > > ------------------------------------- > > > > $ make lzo > > [snip] > > $ make extensions > > gcc -Wall -g -shared -rdynamic -o dminfo.so dminfo.c -fPIC -DX86_64 > -DLZO -DGDB_10_2 > > gcc -Wall -g -shared -rdynamic -o echo.so echo.c -fPIC -DX86_64 -DLZO > -DGDB_10_2 > > Cloning into 'eppic'... > > remote: Enumerating objects: 268, done. > > remote: Counting objects: 100% (51/51), done. > > remote: Compressing objects: 100% (44/44), done. > > remote: Total 268 (delta 4), reused 31 (delta 4), pack-reused 217 > > Receiving objects: 100% (268/268), 256.48 KiB | 2.49 MiB/s, done. > > Resolving deltas: 100% (93/93), done. > > cd eppic/libeppic && make > > bison -peppic -v -t -d eppic.y > > eppic.y: warning: 253 shift/reduce conflicts [-Wconflicts-sr] > > eppic.y: warning: 20 reduce/reduce conflicts [-Wconflicts-rr] > > eppic.y: note: rerun with option '-Wcounterexamples' to generate > conflict counterexamples > > cc -g -fno-omit-frame-pointer -fPIC -c -o eppic_util.o eppic_util.c > > cc -g -fno-omit-frame-pointer -fPIC -c -o eppic_node.o eppic_node.c > > cc -g -fno-omit-frame-pointer -fPIC -c -o eppic_var.o eppic_var.c > > cc -g -fno-omit-frame-pointer -fPIC -c -o eppic_func.o eppic_func.c > > cc -g -fno-omit-frame-pointer -fPIC -c -o eppic_str.o eppic_str.c > > cc -g -fno-omit-frame-pointer -fPIC -c -o eppic_op.o eppic_op.c > > cc -g -fno-omit-frame-pointer -fPIC -c -o eppic_num.o eppic_num.c > > cc -g -fno-omit-frame-pointer -fPIC -c -o eppic_stat.o eppic_stat.c > > cc -g -fno-omit-frame-pointer -fPIC -c -o eppic_builtin.o > eppic_builtin.c > > cc -g -fno-omit-frame-pointer -fPIC -c -o eppic_type.o eppic_type.c > > cc -g -fno-omit-frame-pointer -fPIC -c -o eppic_case.o eppic_case.c > > cc -g -fno-omit-frame-pointer -fPIC -c -o eppic_api.o eppic_api.c > > cc -g -fno-omit-frame-pointer -fPIC -c -o eppic_member.o eppic_member.c > > cc -g -fno-omit-frame-pointer -fPIC -c -o eppic_alloc.o eppic_alloc.c > > cc -g -fno-omit-frame-pointer -fPIC -c -o eppic_define.o eppic_define.c > > cc -g -fno-omit-frame-pointer -fPIC -c -o eppic_input.o eppic_input.c > > cc -g -fno-omit-frame-pointer -fPIC -c -o eppic_print.o eppic_print.c > > bison -peppicpp -v -t -d eppicpp.y > > eppicpp.y: warning: 23 shift/reduce conflicts [-Wconflicts-sr] > > eppicpp.y: note: rerun with option '-Wcounterexamples' to generate > conflict counterexamples > > cc -g -fno-omit-frame-pointer -fPIC -c eppicpp.tab.c > > cc -g -fno-omit-frame-pointer -fPIC -c eppic.tab.c > > flex -L -Peppic -t eppic.l > lex.eppic.c > > cc -g -fno-omit-frame-pointer -fPIC -c lex.eppic.c > > flex -Peppicpp -t eppicpp.l > lex.eppicpp.c > > cc -g -fno-omit-frame-pointer -fPIC -c lex.eppicpp.c > > cc -g -fno-omit-frame-pointer -fPIC -o mkbaseop mkbaseop.c > > ./mkbaseop > baseops.c > > cc -g -fno-omit-frame-pointer -fPIC -c baseops.c > > ar cur libeppic.a eppic_util.o eppic_node.o eppic_var.o eppic_func.o > eppic_str.o eppic_op.o eppic_num.o > > eppic_stat.o eppic_builtin.o eppic_type.o eppic_case.o eppic_api.o > eppic_member.o eppic_alloc.o > > eppic_define.o eppic_input.o eppic_print.o eppicpp.tab.o eppic.tab.o > lex.eppic.o lex.eppicpp.o baseops.o > > gcc -g -Ieppic/libeppic -I../gdb-10.2/gdb -I../gdb-10.2/bfd > -I../gdb-10.2/include > > -I../gdb-10.2/gdb/config -I../gdb-10.2/gdb/common -I../gdb-10.2 > -nostartfiles -shared -rdynamic -o > > eppic.so eppic/applications/crash/eppic.c -fPIC -DX86_64 -DGDB_10_2 > -Leppic/libeppic -leppic > > In file included from ../gdb-10.2/gdb/defs.h:28, > > from eppic/applications/crash/eppic.c:22: > > ../gdb-10.2/gdbsupport/common-defs.h:90:10: fatal error: cstdlib: No > such file or directory > > 90 | #include <cstdlib> > > | ^~~~~~~~~ > > compilation terminated. > > make[4]: [eppic.mk:67: eppic.so] Error 1 (ignored) > > gcc -Wall -g -I. -shared -rdynamic -o snap.so snap.c -fPIC -DX86_64 > -DLZO -DGDB_10_2 > > > ------------------------------------------------------------------------------------------------------ > > -------- > > > > > > Exactly the same problem is occurring on s390 architecture. > > > > I find it's very weird that a C library like eppic is including a C++ > > header from GDB. > > > > gdb-10.2/gdbsupport/common-defs.h is a C++ header containing includes of > > other C++ headers like cstdlib, array etc. Furthermore, it contains C++ > > templates ! > > > > Has anybody tested this ? Maybe i'm doing something wrong :/ > > Would appreciate any hint how to fix this. So far i haven't figured out > > howto fix this and we depend on eppic extension. > > > > > > Thanks > > Regards > > Alex > >
-- Crash-utility mailing list [email protected] https://listman.redhat.com/mailman/listinfo/crash-utility
