| 1 |
On 05/06/12 00:21, Paul Hartman wrote: |
| 2 |
> On Mon, Jun 4, 2012 at 3:19 PM, Nikos Chantziaras<realnc@×××××.com> wrote: |
| 3 |
>> I've emerged system and world with gcc-4.7.0 and LTO. I'm posting from it |
| 4 |
>> right now :-) It's a KDE system with 1043 packages installed. |
| 5 |
>> |
| 6 |
>> I've posted details on how to do this (including info on how to disable LTO |
| 7 |
>> for specific packages that don't work with it) here: |
| 8 |
>> |
| 9 |
>> http://realnc.blogspot.com/2012/06/building-gentoo-linux-with-gcc-47-and.html |
| 10 |
> [...] |
| 11 |
> Do you have any measure of compile times using lto compared to not using it? |
| 12 |
|
| 13 |
It was pretty obvious without doing any actual measurement: linking is |
| 14 |
slower with LTO. Large programs even take several minutes for the link |
| 15 |
step. |
| 16 |
|
| 17 |
|
| 18 |
> Was there any effect on quality of debugging info in the resulting |
| 19 |
> binaries? I thought I read at some point there was no (or bad) debug |
| 20 |
> info with LTO. Maybe I'm thinking about clang, though. |
| 21 |
|
| 22 |
Didn't notice anything strange yet. But I suspect that this isn't |
| 23 |
important to begin with; all we need are backtraces. Thorough debugging |
| 24 |
symbols are not important for emerged packages. |
| 25 |
|
| 26 |
|
| 27 |
> Did you use gold or the standard linker? |
| 28 |
|
| 29 |
The standard one. I didn't actually think about the importance of this. |
| 30 |
Does gold work better with LTO? |
Archives