Linking runtime libraries as fat LTO objects?

Hi Michael,

This has the potential to virtually double the number of multilibs to be built as we will have to keep the present ones so that we don't increase their size.

Would you be open to trying to build LTO libs yourself?

We supply all the build scripts and the sources and there are detailed build instructions attached to the released tarballs. We can support you in this process if necessary.

Thanks,
Tejas.

Hi all,

LTO libs could be offered as separate downloads. Also, new bugs are highly likely to show up, since this scenario (LTO libs) is not well-tested.
But the idea is intriguing.

I'm looking into building it now. Have to set up an Ubuntu VM to do so.

Why would you need to still keep the present libraries? I'm confused as to why they need to stay the same size - fat LTO objects would still include the machine-code variant in the object file as well, so they should still be able to link to the same form. The archive file would be larger, but the actual code being linked should be the same size for a regular link.

Just as an update to you guys ---

When building under Ubuntu (18 Pre-Release, at least)... two issues came up that your documentation didn't cover:

1. I had to install mingw through apt-get.
2. I had to update at least libiconv as the version you have has a bug that causes it to fail linking with current gcc. This was fixed in 1.15. I took the liberty locally of updating all of the support libs:
  * GMP 6.1.0 -> 6.12
  * MPFR 3.1.4 -> 4.0.1
  * MPC 1.0.3 -> 1.1.0
  * ISL 0.15 -> 0.19
  * EXPAT 2.1.1 -> 2.2.5
  * LIBICONV 1.14 -> 1.15
  * ZLIB 1.2.8 -> 1.2.11
  * PYTHON_WIN_VER 2.7.13 -> 2.7.14

Some of them were _very_ out of date, and that seems dangerous for some of these libraries.

Hi Michael,

Thanks for the update. As the doc says, we haven't built it on a system after 14.04 LTS 64-bit. So these are new problems that one may face - thanks for the feedback.

As for mingw builds, you could skip it using --skip_steps=mingw32 - the target libraries don't depend on it.

Could you please elaborate on the bug you discovered with libiconv 1.14?

Thanks,
Tejas.
.

I unfortunately use Windows as the primary development system for this, so I need the mingw build. I've run into a few issues building for mingw, but I think I've gotten past them.

The issue I had with libiconv appears to be related to these:

https://savannah.gnu.org/bugs/?47953
https://github.com/spack/spack/issues/6613

With the undefined reference.

1.14 was released back in 2011, and the fix for this was put in in November 2016, with 1.15 being released in February 2017. Updating libiconv to 1.15 resolved the issue.

Hi Michael,

Thanks for the info.

What I meant about the mingw build was that you could build the LTO-enabled libs on the Ubuntu VM by skipping the mingw32 tools build and just use the pre-built mingw tools binaries we release to link the lto libs. Won't that work?

But if you've already managed to fix your mingw issues, that's fine. Just curious, were the mingw issues related to the new Ubuntu platform?

Thanks,
Tejas.

The main mingw issues were due to mingw not natively being installed on the system.

There were other mingw issues involved with some things I were testing, but appear to be long-term issues with mingw-gcc itself that, while reported, appear to never have been fixed. Unusual errors with -fuse-linker-plugins and the like.

From https://gcc.gnu.org/onlinedocs/gccint/LTO-object-file-layout.html :

"Currently, GCC does not support combining LTO object files compiled with different set of the command line options into a single binary."

Sounds like that would mean LTO might not be good for built-in libraries. Although it doesn't say what kind of option mismatches are problematic. Some options of course need to match with a regularly built lib as well (such as ABI options), hence the variety of multilibs. But perhaps the set of options of this kind are much bigger with LTO (optimization options?) which could make it impractical to build multilibs for all combinations.