Khem Raj <raj.k...@gmail.com> writes: >> gcc-10+ supports zstd compression of LTO bytecode. Install the >> corresponding package to enable this feature in a deterministic way. >> >> NOTE: previously built LTO object files (without this compression) >> must be regenerated; gcc will fail else with >> >> | lto1: internal compiler error: original not compressed with zstd >> >> in this case. >> >> NOTE: it seems to be possible that zstd support is enabled non >> deterministically (perhaps by host system pollution). >> >> I had the problem that the SDK gcc was built with zstd while the >> cross gcc was built without it. Libraries (built by cross gcc and >> uncompressed hence) could not be used with the SDK gcc. > > this means regenerating entire shared state isnt it ?
yes (at least when lto.inc is used (which is *not* by default)). When a bad sstate really matters for 'master', perhaps there can be wait for a change in glibc or so before applying this patch. Or do you think that adding a DISTRO_FEATURE like 'lto-zstd' would make sense? When this flag is missing, '--without-zstd' must be added to EXTRA_OECONF. Also some early [vardeps] must be set (where?) to avoid the sstate problem. Globally enabling 'zstd' appears easier because drawbacks (costs for compression + decompression) should be negligible for zstd. Enrico
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#161320): https://lists.openembedded.org/g/openembedded-core/message/161320 Mute This Topic: https://lists.openembedded.org/mt/88888010/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
