------- Comment #12 from joseph at codesourcery dot com 2009-10-09 12:58 ------- Subject: Re: plugin-api.h unconditionally includes stdint.h
On Fri, 9 Oct 2009, ro at techfak dot uni-bielefeld dot de wrote: > ------- Comment #10 from ro at techfak dot uni-bielefeld dot de 2009-10-09 > 12:42 ------- > Subject: Re: plugin-api.h unconditionally includes stdint.h > > > ------- Comment #9 from espindola at google dot com 2009-10-08 18:20 > > ------- > [...] > > The only thing the compiler should need the plugin-api.h for is the enum > > ld_plugin_symbol_resolution. If we split plugin-api.h in two, we would be > > able > > to compile gcc itself without stdint.h. > > > > The problem with this approach is that the lto plugin would still fail to > > build > > in a system without stdint.h. Is it OK to have optional features like the > > gold > > plugin not supported in systems like "Tru64 UNIX V4.0F"? > > That would be no problem since AFAIK gold only supports ELF targets by > design, and Tru64 UNIX uses ECOFF. Not even GNU ld supports that anymore > (or the support has bitrotten to the point of being unusable). gold supports non-ELF hosts (or will once Andrew Pinski's MinGW host patches are in), and in due course should support plugins on such hosts. (I've no idea whether Tru64 has a dynamic loading interface making plugins on such a host possible at all, but if it has such an interface there is no reason in principle against someone adding support for plugins for a cross compiler and linker from Tru64 to an ELF target.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40790