Bug 206467

Summary: trace-cmd fail to build with gcc 10 due to multiple definition of `common_type_field'
Product: Tools Reporter: Ziqian SUN (Zamir) (sztsian)
Component: Trace-cmd/KernelsharkAssignee: Default virtual assignee for Trace-cmd and kernelshark (tools_tracecmd_kernelshark)
Status: RESOLVED CODE_FIX    
Severity: normal CC: rostedt, tstoyanov
Priority: P1    
Hardware: All   
OS: Linux   
Kernel Version: trace-cmd-2.8.3 Subsystem:
Regression: No Bisected commit-id:

Description Ziqian SUN (Zamir) 2020-02-08 14:12:53 UTC
GCC 10 now defaults to -fno-common.

https://gcc.gnu.org/gcc-10/changes.html

And when building against gcc 10, it will fail

<mock-chroot> sh-5.0# make

... snip ...

  BUILD                  trace-cmd
/usr/bin/ld: /builddir/build/BUILD/trace-cmd-v2.8.3/tracecmd/trace-mem.o:/builddir/build/BUILD/trace-cmd-v2.8.3/tracecmd/trace-mem.c:33: multiple definition of `common_type_field'; /builddir/build/BUILD/trace-cmd-v2.8.3/tracecmd/trace-hist.o:/builddir/build/BUILD/trace-cmd-v2.8.3/tracecmd/trace-hist.c:30: first defined here
collect2: error: ld returned 1 exit status
make[1]: *** [Makefile:60: /builddir/build/BUILD/trace-cmd-v2.8.3/tracecmd/trace-cmd] Error 1
make: *** [Makefile:273: trace-cmd] Error 2
<mock-chroot> sh-5.0# gcc --version
gcc (GCC) 10.0.1 20200130 (Red Hat 10.0.1-0.7)
Copyright (C) 2020 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.

Checking the code it shows that it is really from the code itself.

$ git log -1 --oneline
e8fb011 (HEAD -> master, upstream/master) trace-cmd: Have /etc paths honor $(prefix) if not the default
$ grep 'common_type_field;' * -R
tracecmd/trace-hist.c:struct tep_format_field *common_type_field;
tracecmd/trace-mem.c:struct tep_format_field *common_type_field;

I think the simple fix is to rename common_type_field to others in tracecmd/trace-mem.c but I'd leave it to maintainers to decide a proper fix.

Right now my workaround is to add '-z muldefs' in LDFLAGS.
Comment 1 Tzvetomir Stoyanov 2020-02-10 08:53:51 UTC
Hi Zamir,

Thanks for testing and reporting this! I've just submitted a fix

https://patchwork.kernel.org/patch/11372767/

--
Tzvetomir Stoyanov (VMware)
Comment 2 Steven Rostedt 2020-03-02 20:24:25 UTC
Fixed by de7941659add ("trace-cmd: Fix "multiple definition" compiler errors")