Menu
▾
▴
#1918 Provide libraries compiled with -flto
assigned
Feature
none
Unknown
False
2014-01-23
2012-06-14
No
If possible, could MinGW provide libraries compiled with -flto option?
That would be mingwrt libraries (libmingw32.a, libmingwex.a, ...), and libstdc++, libgcc and others that actually contain code (libiconv, libz, ...). This would lead to smaller and/or faster code when one chooses to link the whole program with -flto. Thanks for consideration.
Discussion
Would this require needing lto enabled libraries and non-lto enabled libraries depending on usage? If so then we need a consensus from the MinGW community which way we should go with it because encumbering us with multiple library distributions is not going to happen.
No, no multiple library distributions are needed. Since the LTO informations are added as a completely new sections in the .o/.a files, such files can be linked interchangeably with files without LTO informations. AFAIK the linker, when invoked with -flto, will employ LTO information from files that contain it, while linking files without LTO the classic way.
Ticket moved from /p/mingw/feature-requests/113/
Keith, I've assigned to you for your input.
Hi, I just wanted to report that I have tried building libcrt, libmingw32 and libmingwex with -flto (just added the flag to makefile) and it works well for me. Although I have tested it on just a few projects of mine, the resulting executables are up to ~15kB smaller for projects compiled and linked with -flto. There is no difference (for me) when not linking with -flto.
I would love to try both libsupc++ and libstdc++ compiled with -flto. I have tried to build MinGW myself, but I am apparently missing serious amount of knowledge to manage to do that.
According to http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59893, it is (currently) not a good idea to enable -flto by default.