DUP FUNXC when stripping zfcpdump_part

[sharkcz]

Rebuild of s390-tools master in Fedora Rawhide (gcc-9.1.1-2.fc31.s390x and binutils-2.32-17.fc31.s390x) prints dozens of "DUP FUNXC" messages, see bellow.

...
gcc -rdynamic zfcpdump.o zfcpdump_part.o -static -o zfcpdump_part
gcc -I ../include -D_GNU_SOURCE -DSYSFS -DS390_TOOLS_RELEASE=2.9.0-build-20190712 -DS390_TOOLS_LIBDIR=/lib/s390-tools -DS390_TOOLS_DATADIR=/usr/share/s390-tools -DS390_TOOLS_SYSCONFDIR=/etc -DS390_TOOLS_BINDIR=/sbin -g -rdynamic -fstack-protector-all -W -Wall -Wformat-security -O3  -DHAVE_SETXATTR -pthread -I/usr/include/fuse -D_FILE_OFFSET_BITS=64  -c zdsfs.c -o zdsfs.o
strip -s zfcpdump_part
DUP FUNXC
DUP FUNXC
DUP FUNXC
DUP FUNXC
DUP FUNXC
DUP FUNXC
DUP FUNXC
...

[hoeppnerj]

I have only binutils-2.31.1-29.1.fc30.src.rpm and gcc-9.1.1-1.fc30.src.rpm available here at the moment and can't reproduce your issue with those version. Is there a way to install your versions of gcc and binutils on an F30 installation? Can I download the rpms already somewhere and install them manually or so?

[sharkcz]

The old school method is to use a Rawhide chroot prepared by the mock tool. It can be managed by the package maintainers' fedpkg tool.

I've just used following to reproduce

fedpkg co s390utils
cd s390utils
fedpkg mockbuild --no-cleanup-after

It checks out the s390utils package and rebuilds in a fresh rawhide chroot with all deps installed. Then with mock -r fedora-rawhide-s390x shell you enter the chroot, the build directory is /builddir/build/BUILD/s390-tools-2.9.0/. See mock(1) for how to use mock (install additional rpms, etc). Or ping me on IRC if you have more questions.

[sharkcz]

Or use containers :-)

podman run -it fedora:rawhide

[sharkcz]

No such issue in recent Fedoras, closing.