On Thu, 18 Jul 2019, Florian Weimer wrote:
> > Right and stable LTO bytecode really isn't on the radar at this time.
>
> Maybe it's better to serialize the non-preprocessed source code instead.
> It would need some (hash-based?) deduplication. For #include
> directives, the hash of the file would be captured for reproducibility.
> Then if the initial #defines are known, the source code after processing
> can be reproduced exactly.
>
> Compressed source code is a surprisingly compact representation of a
> program, usually smaller than any (compressed) IR dump.
Hi,
That may fly in the open source world, however I expect some vendors
shipping proprietary code might be fine with assembly/LTO representation
of their product, but not source.
It looks like from your different answers that for now it's hopeless to
expect good compatibility between minor releases. With that in mind, do
you think it might be worth implementing some kind of flag
-flto-fallback-to-fat-objects={error,warning,silent} where the default
value would be "error" (just say that we have an LTO version mismatch),
"warning" would just print the version mismatch, but fallback to fat
assembly for the conflicting libraries, and "silent" would do that same
fallback silently ? Or are we really the only users of fat LTO objects
and the only ones to face these kind of issues where rebuilding
everything all the time is not easy/possible ?
Cheers,
Romain
