https://blogs.gentoo.org/ago/2020/07/04/gentoo-tinderbox/ Issue: net-vpn/openvpn-2.5.7 fails tests (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 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
Created attachment 824843 [details] build.log build log and emerge --info
Error(s) that match a know pattern in addition to what has been reported in the summary: <artificial>:(.text+0x1316): undefined reference to `__wrap_parse_line' collect2: error: ld returned 1 exit status
Still in openvpn-2.6.8
OpenVPN upstream here. This is cmocka based unit test code, with gcc being called with `-Wl,--wrap=parse_line` to, well, create a link-time wrapper for `parse_line()` (which would then be __wrap_parse_line(), provided by test_argv.c). As far as I can see, the C signatures match, so there is no reason why `-flto` should be complaining here. OTOH, -Wl,-wrap is documented as "only undefined references are replaced by the linker" and maybe this fails if the linker considers all .o files as "one" (but then I'd expect a complaint about `parse_line()` which would indeed be not present). In other words: I think the compiler upsets itself here, and I do not see anything we could do about it (except not use -Wl,-wrap= and rewrite our unit test code).
reproducible with net-vpn/openvpn-2.6.9
Hi Gert, thank you for commenting! What I find interesting here is that supposedly wrap *is* supposed to work with LTO (https://sourceware.org/bugzilla/show_bug.cgi?id=24406) but it doesn't here, but I've seen this kind of failure with other packages doing exactly what OpenVPN is. I may try reduce it to either better understand it and/or report a bug if there is one.
I've tried to reduce it and reported it as a bfd bug at https://sourceware.org/bugzilla/show_bug.cgi?id=31956. I'm not sure if it's a real bug or if instead we need to workaround/adjust packages, let's see.
H.J has kindly provided a patch (https://sourceware.org/pipermail/binutils/2024-July/135445.html) which makes OpenVPN tests build (they fail at runtime for an unrelated reason, fail with mold too with LTO, need to look into this). It also fixes bug 877755 at least.
Good news: there was a bfd bug here which H.J. Lu has posted a patch for! (https://sourceware.org/bugzilla/show_bug.cgi?id=31956) Bad news: the tests fail execution (runtime) because the real definition of e.g. buffer_write_file is visible and could be inlined. It needs to be firewalled via e.g. an internal shared library.
