Jiahao XU
Jiahao XU
@Altair-Bueno you need to enable linker lto plugin, otherwise rustc would perform LTO on rust and C code separately, and then link them together
Won't `-flto` able to optimize within the C/C++ library, even if it cannot be optimized across language boundaries? Alternatively it'd be great if it's possible to perform lto on all...
> Is it "won't fix"? I do want to fix this, just want to check to see if we can keep the benefit of LTO inside the C/C++ library.
Did some research, for clang it seems to support this ```bash llvm-link file1.bc file2.bc file3.bc -o merged.bc llc merged.bc -filetype=obj -o merged.o ``` I didn't find anyway to achieve that...
So we could just fix this, having -flto on -Clinker-plugin-LTO And then we could add back c/c++ internal LTO for clang/zig-cc
Yeah it makes sense, it seems the best now to - ignore -Clto - for -Clinker-plugin-LTO, uses -flto Better than what we have now, with -Clto potentially breaking the build....
Thanks, LGTM
Note that we do support `CC_{target}` and `CFLAGS_{target}`, so if you are changing `PATH`, might as well use `CC_{target}`?
This error is introduced in #412 https://github.com/Nullus157/async-compression/blob/8947fed0e01237e6763b77e3fe15604dab7b6d32/crates/compression-codecs/src/zstd/decoder.rs#L90 It would occur when the zstd file is partially decompressed. You might want to ignore this error, if this behavior is intentional
Hmm I don't know how you are using our library. Is it directly through codec, or indirectly through tokio/futures-io bufread/write implementation?