When building a dependent crate with CXXFLAGS="-flto" we see a bunch of
undefined references to functions coming from libnitrokey [0]. E.g.,
> = note: ld: nitrokey-rs/target/debug/deps/libnitrokey-f907de21b60ae79e.rlib(nitrokey-f907de21b60ae79e.2sba6cpuq76jpx3j.rcgu.o):
> in function `nitrokey::get_library_version':
> nitrokey-rs/src/lib.rs:623: undefined reference to `NK_get_library_version'
It's not exactly clear why that is: All generated rlibs seem to have the
proper symbols in both cases, with and without LTO. That leaves tooling
incompatibilities as a potential culprit [1], but superficially that did
not seem to be the case either, as swapping out ar for gcc-ar did not
make any difference.
To fix this problem, this change proposes the addition of the -fno-lto
flag to the libnitrokey build. The size of the nitrocli binary built in
release mode, i.e., with full LTO enabled through Cargo but without any
CXXFLAG dance, yields exactly the same size with and without this
change, suggesting that this addition does not interfere with the magic
that Cargo does when doing LTO enabled builds.
[0]: https://bugs.gentoo.org/854228
[1]: https://stackoverflow.com/questions/25878407/how-can-i-use-lto-with-static-libraries
---
build.rs | 1 +
1 file changed, 1 insertion(+)
diff --git a/build.rs b/build.rs
index 0ff6c6..aa8c92 100644
--- a/build.rs
@@ -111,6 +111,7 @@ fn main() {
cc::Build::new()
.cpp(true)
.flag("-std=c++14")
+ .flag("-fno-lto") .include(library_path.join("libnitrokey"))
.files(sources.iter().map(|s| library_path.join(s)))
.file(version_source)
--
2.35.1
nitrokey-sys-rs/patches/archlinux.yml: SUCCESS in 7m2s
[Make sure not to use LTO during build][0] from [Daniel Mueller][1]
[0]: https://lists.sr.ht/~ireas/nitrokey-rs-dev/patches/33304
[1]: mailto:deso@posteo.net
✓ #788158 SUCCESS nitrokey-sys-rs/patches/archlinux.yml https://builds.sr.ht/~ireas/job/788158