[m-users.] Compiler build failure with --enable-lto (was: Link-time optimization)

[M McDonough]

On 15/06/2020 00:13, Massimo Dentico wrote:
>> It's not just enough to put the LTO flags in the CFLAGS, since the
>> standard library (which accounts for much of the executable size in my
>> experience).
>>
>> There is an LTO option during configuration, although I only seriously
>> tested it for MSVC since that's my main target on Windows and shared
>> libraries aren't possible with Mercury in that configuration. That
>> will reduce the resulting exe file by quite a lot.
>>
>> The LTO flags are implemented for gcc and clang as well as MSVC, but I
>> am unsure if it's done in an optimal way (a large part of why it's
>> marked as experimental I believe).
>>
>> Using LTO will also cause the linking steps to be quite long, since
>> it's basically compiling the entire Mercury runtime and standard
>> library at that point. But the file size is quite a bit smaller. The
>> actual performance change is pretty minor from my experience over just
>> intermodule optimization, since intermodule-optimization tends to be
>> very effective before the actual grade's compiler even gets the code.
> Unfortunately the Mercury compiler build with "--enable-lto" failed in
> my configuration. It seems is failing right while linking.
>
> This is the error message and a few lines before the build failure
> (shortened, where there is [...] there was a wall full of .o files):

Yeah, something is wrong there, although I don't really know what
(maybe we need different flags for ar, or to fiddle with whole-archive
settings, or one of the "prune" sections flags?). I mostly tested on
MSVC to make sure it worked, and Clang on OpenBSD to make sure it at
least compiled. I didn't try to use it with GCC on Windows at all.
It's most reliable on Windows with MSVC at this point, although it
would be great if it did work with GCC on Windows :(