Re: Some questions

[Rich Felker <dalias@libc.org>]

On Mon, Apr 30, 2018 at 03:17:11PM +1000, Patrick Oppenlander wrote:
> On Mon, Apr 30, 2018 at 1:16 PM, Rich Felker <dalias@libc.org> wrote:
> >> - Are there any plans to support static linking with LTO?
> >
> > It should be possible, but gcc mishandles the crt files when doing
> > LTO. I think if you suppress LTO for them it works. Someone posted
> > results experimenting with it either on the list or IRC channel
> > recently. I'll see if I can find anything useful.
> 
> Last time I tried to LTO a C library I ran into this:
> 
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63215#c1

I don't quite understand the issue as reported there. The example is
defining abs in a way that could be self-referential in the absence of
-fno-builtin or -ffreestanding (which implies -fno-builtin). But the
use of -ffreestanding is always necessary to build a libc. This is in
no way specific to LTO.

Anyway I don't think this issue affects musl but I'm not sure.

> I ended up building parts of the library as -fno-lto which worked but
> was fairly painful.
> 
> But that was 2014, so maybe the situation is different now.

The issue I'm aware of is that the reference to _start_c from the
top-level asm _start function is not seen by LTO. This should be
possible to work around just by teaching configure to check if
-fno-lto is supported, and if so having the Makefile pass it for crt
files. But I'm skeptical that you'd get much benefit applying LTO to
musl itself. It's known that you don't for producing a shared library
(ppl have tested this), but static may fare better. In theory a really
smart LTO could optimize out the whole floating point support from
printf when all formst strings are literals and none contain %f's, but
in practice none are anywhere near that smart.

Rich