https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118136
--- Comment #9 from Torbjorn SVENSSON <azoff at gcc dot gnu.org> --- (In reply to Andrew Pinski from comment #8) > (In reply to Torbjorn SVENSSON from comment #7) > > So, if I understand you correctly Andrew, it's impossible to write the start > > code in C for a free-standing application and build it with -flto into a > > library and then reuse that? > > I.e. think of the case where newlib is built with -flto -ffat-lto-objects > > and then the consumer of the library is built with -flto. > > It is possible to write the start code in C code for a free standing > application. Just the C rules for main for hosted env don't applies then; it > becomes a normal function. I don't think you understood where my question is heading. Obvious, the reproducer I shared is just a minimal example. In the case where the developer have control over both sides, it's easy to align it. In the case where the startup routine is in a library, it may not be as simple. So, to repeat my question that I feel got missed. Lets consider that my vendor provided toolchain comes with newlib compiled with -flto -ffat-lto-objects (and that the function calling main is written in C using the `int main(int,char**)` signature). In my application, I'm using the signature `int main()`. When I build my application, everything goes well (no warning at least) as long as I do not use -flto. If I decide to enable LTO using the -flto compiler option, then I suppose the warning is generated as the signature for "main" in my application differs from what was included in the library (newlib in this scenario). Is this scenario supposed to work or fail?
