https://blogs.gentoo.org/ago/2020/07/04/gentoo-tinderbox/ Issue: net-libs/libnetconf2-2.1.11 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 824597 [details] build.log build log and emerge --info
Created attachment 824599 [details] 1-LastTest.log 1-LastTest.log
Error(s) that match a know pattern in addition to what has been reported in the summary: 8 - test_server_thread (Failed) 11 - test_client_ssh (Failed) -- Could NOT find Doxygen (missing: DOXYGEN_EXECUTABLE)
Updating to upstream 3.0.8 does NOT help as that version fails to compile instead.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=9dc2b0c59ee947b470757ffc8d62c0f85a4b1f84 commit 9dc2b0c59ee947b470757ffc8d62c0f85a4b1f84 Author: Eli Schwartz <eschwartz93@gmail.com> AuthorDate: 2024-03-25 15:29:42 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2024-03-26 12:24:30 +0000 net-libs/libnetconf2: mark as LTO-unsafe It fails tests which seems like a promising sign that something unpromising happened. Closes: https://bugs.gentoo.org/877449 Signed-off-by: Eli Schwartz <eschwartz93@gmail.com> Signed-off-by: Sam James <sam@gentoo.org> net-libs/libnetconf2/libnetconf2-2.1.31.ebuild | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-)
The upstream bug was closed as they couldn't reproduce: https://github.com/CESNET/libnetconf2/issues/471#issuecomment-2024538214
This is most probably duplicate of the bug 872149 rather than LTO issue.
FAILED: tests/test_client_tls : && /usr/bin/x86_64-pc-linux-gnu-gcc -march=native -fstack-protector-all -O2 -pipe -fdiagnostics-color=always -frecord-gcc-switches -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=3 -fstack-clash-protection -flto=4 -Werror=odr -Werror=lto-type-mismatch -Werror=strict-aliasing -Wformat -Werror=format-security -Werror=implicit-function-declaration -Werror=implicit-int -Werror=int-conversion -Werror=incompatible-pointer-types -Wall -Wextra -fvisibility=hidden -std=c99 -DNC_ENABLED_SSH_TLS -Wl,-O1 -Wl,--as-needed -flto=4 -Werror=odr -Werror=lto-type-mismatch -Werror=strict-aliasing -Wl,--defsym=__gentoo_check_ldflags__=0 -Wl,--wrap=connect,--wrap=SSL_connect,--wrap=nc_send_hello_io,--wrap=nc_handshake_io,--wrap=nc_ctx_check_and_fill tests/CMakeFiles/testobj.dir/__/src/io.c.o tests/CMakeFiles/testobj.dir/__/src/log.c.o tests/CMakeFiles/testobj.dir/__/src/messages_client.c.o tests/CMakeFiles/testobj.dir/__/src/messages_server.c.o tests/CMakeFiles/testobj.dir/__/src/session.c.o tests/CMakeFiles/testobj.dir/__/src/session_client.c.o tests/CMakeFiles/testobj.dir/__/src/session_server.c.o tests/CMakeFiles/testobj.dir/__/src/server_config.c.o tests/CMakeFiles/testobj.dir/__/src/server_config_util.c.o tests/CMakeFiles/testobj.dir/__/src/session_client_ssh.c.o tests/CMakeFiles/testobj.dir/__/src/session_server_ssh.c.o tests/CMakeFiles/testobj.dir/__/src/server_config_util_ssh.c.o tests/CMakeFiles/testobj.dir/__/src/session_client_tls.c.o tests/CMakeFiles/testobj.dir/__/src/session_server_tls.c.o tests/CMakeFiles/testobj.dir/__/src/server_config_util_tls.c.o tests/CMakeFiles/testobj.dir/__/src/server_config_ks.c.o tests/CMakeFiles/testobj.dir/__/src/server_config_ts.c.o tests/CMakeFiles/testobj.dir/__/compat/compat.c.o tests/CMakeFiles/test_client_tls.dir/test_client_tls.c.o -o tests/test_client_tls -Wl,-rpath,/var/tmp/portage/net-libs/libnetconf2-3.0.8/work/libnetconf2-3.0.8_build /usr/lib64/libcmocka.so /usr/lib64/libyang.so libnetconf2.so.4.1.5 /usr/lib64/libssl.so /usr/lib64/libcrypto.so /usr/lib64/libssh.so /usr/lib64/libcurl.so -lcrypt /usr/lib64/libpam.so /usr/lib64/libyang.so && : /var/tmp/portage/net-libs/libnetconf2-3.0.8/work/libnetconf2-3.0.8/src/session_server_ssh.c: In function ‘nc_session_ssh_msg’: /var/tmp/portage/net-libs/libnetconf2-3.0.8/work/libnetconf2-3.0.8/src/session_server_ssh.c:1094:17: warning: ‘pubkey_count’ may be used uninitialized [-Wmaybe-uninitialized] 1094 | uint16_t i, pubkey_count; | ^ /usr/lib/gcc/x86_64-pc-linux-gnu/13/../../../../x86_64-pc-linux-gnu/bin/ld: /tmp/ccGCkpH1.ltrans4.ltrans.o: in function `nc_connect_tls': <artificial>:(.text+0xb649): undefined reference to `__wrap_SSL_connect' /usr/lib/gcc/x86_64-pc-linux-gnu/13/../../../../x86_64-pc-linux-gnu/bin/ld: /tmp/ccGCkpH1.ltrans1.ltrans.o: in function `nc_accept_callhome': <artificial>:(.text+0x7e3c): undefined reference to `__wrap_SSL_connect' collect2: error: ld returned 1 exit status Maybe that was fixed by binutils though.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=bca98fa9af4ca148f728b729dc0d83725b8ff970 commit bca98fa9af4ca148f728b729dc0d83725b8ff970 Author: Petr Vaněk <arkamar@gentoo.org> AuthorDate: 2025-06-09 11:58:12 +0000 Commit: Petr Vaněk <arkamar@gentoo.org> CommitDate: 2025-06-09 14:07:30 +0000 net-libs/libnetconf2: add 3.7.1 This version passes all tests with both sets of LTO related flags from bug 877449, therefore filter-lto is dropped. Bug: https://bugs.gentoo.org/877449 Signed-off-by: Petr Vaněk <arkamar@gentoo.org> net-libs/libnetconf2/Manifest | 1 + net-libs/libnetconf2/libnetconf2-3.7.1.ebuild | 48 +++++++++++++++++++++++++++ 2 files changed, 49 insertions(+)
(In reply to Eli Schwartz from comment #8) > Maybe that was fixed by binutils though. Could be, I tested newest version also with your flags and all tests pass.
