https://blogs.gentoo.org/ago/2020/07/04/gentoo-tinderbox/ Issue: net-analyzer/fragroute-1.2.6-r4 fails to compile (lto). Discovered on: amd64 (internal ref: lto_tinderbox) NOTE: This machine uses lto with CFLAGS=-flto -Werror=odr -Werror=lto-type-mismatch -Werror=strict-aliasing
Created attachment 794441 [details] build.log build log and emerge --info
Here is a bit of explanation: -Werror=lto-type-mismatch: User to find possible runtime issues in packages. It likely means the package is unsafe to build & use with LTO. For projects using the same identifier but with different types across different files, they must be fixed to be consistent across the codebase. -Werror=odr: Used to find possible runtime issues in packages. These bugs are a problem anyway but may be even worse when combined with LTO. C++ code must comply with the One Definition Rule (ODR) - see https://en.cppreference.com/w/cpp/language/definition#One_Definition_Rule. -Werror=strict-aliasing: Used to find possible runtime issues in packages. These bugs are a problem anyway but may be even worse when combined with LTO. Workarounds: - If upstream is friendly and still active, file a bug upstream. For emulators, codecs, games, or multimedia packages, it may be worth just applying a workaround instead, as upstreams sometimes aren't receptive to these bugs (VALID FOR ALL). - Use the new 'filter-lto' from flag-o-matic.eclass as it's likely to be unsafe with LTO (VALID FOR lto-type-mismatch - odr). - Fix it yourself if interested, of course (VALID FOR ALL). - Append-flags -fno-strict-aliasing (VALID FOR strict-aliasing). - Use memcpy() but a union is sometimes suitable too (VALID FOR strict-aliasing). - -fstrict-aliasing is implied by -O2, so this must be addressed in some form (VALID FOR strict-aliasing). See also: https://marc.info/?l=gentoo-dev&m=165639574126280&w=2
checking for strlcat... no checking for strlcpy... no [...] x86_64-pc-linux-gnu-gcc -O2 -pipe -march=x86-64 -frecord-gcc-switches -fno-diagnostics-color -fmessage-length=0 -flto -Werror=odr -Werror=lto-type-mismatch -Werror=strict-aliasing -Wall -Wl,-O1 -Wl,--as-needed -Wl,--defsym=__gentoo_check_ldflags__=0 -o fragtest fragtest.o bget.o mod_ip_frag.o pcaputil.o pkt.o randutil.o iputil.o tun-loop.o strlcat.o strlcpy.o -ldnet -lpcap -levent tun-loop.c:288:9: error: type of <E2><80>-Werror=lto-type-mismatch][]] 288 | strlcpy(tun->ifent->intf_name, LOOPBACK_DEV, | ^ strlcpy.c:43:1: note: return value type mismatch 43 | strlcpy(dst, src, siz) | ^ strlcpy.c:43:1: note: type ‘size_t’ should match type ‘int’ strlcpy.c:43:1: note: ‘strlcpy’ was previously declared here strlcpy.c:43:1: note: code may be misoptimized unless ‘-fno-strict-aliasing’ is used tun-loop.c:288:9: error: type of <E2><80>-Werror=lto-type-mismatch][]] 288 | strlcpy(tun->ifent->intf_name, LOOPBACK_DEV, | ^ strlcpy.c:43:1: note: return value type mismatch 43 | strlcpy(dst, src, siz) | ^ strlcpy.c:43:1: note: type ‘size_t’ should match type ‘int’ strlcpy.c:43:1: note: ‘strlcpy’ was previously declared here strlcpy.c:43:1: note: code may be misoptimized unless ‘-fno-strict-aliasing’ is used mod.c:140:25: error: type of <E2><80>-Werror=lto-type-mismatch][]] 140 | strlcat(buf, rule->mod->name, sizeof(buf)); | ^ strlcat.c:45:1: note: return value type mismatch 45 | strlcat(dst, src, siz) | ^ strlcat.c:45:1: note: type ‘size_t’ should match type ‘int’ strlcat.c:45:1: note: ‘strlcat’ was previously declared here strlcat.c:45:1: note: code may be misoptimized unless ‘-fno-strict-aliasing’ is used lto1: some warnings being treated as errors
So the good news here is that current versions of glibc have a strlcat and strlcpy that are non-trash, unlike whatever 2001 edition of it the project vendors. We are no longer affected by this, which is almost sort of a "yay" for ignoring issues for a couple years until they go away (in all seriousness, no, we shouldn't ignore issues for years as usually they won't go away).
