http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50935
Rainer Orth <ro at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |bonzini at gnu dot org
Target Milestone|--- |4.7.0
--- Comment #3 from Rainer Orth <ro at gcc dot gnu.org> 2011-11-21 16:41:54 UTC
---
It took me a while, but the issue turned out to be different:
* Toplevel config/largefile.m4 disables largefile support for 32-bit Solaris,
and both bfd and ld use ACX_LARGEFILE.
* On the other hand, gcc enables largefile support by default, thus the
lto-plugin
is built with it.
* The resulting ld often fails in strange ways, as expected.
* If I build binutils with --enable-largefile, the vast majority of slim LTO
tests suddenly pass, even when binutils ar, nm, and ranlib are nowhere in
PATH, and are not plugin-enabled by default.
I'm undecided how to deal with this: the largefile disabling in largefile.m4 is
only for the benefit of procfs (thus gdb), but bfd/ld cannot know if they are
built in a combined tree. ld cannot easily check if a plugin is largefile
enabled (this would probably be highly system-dependent), and there is no
guarantee that a plugin uses I/O functions at all. Maybe the lto-plugin could
perform some check with dlsym (for open64?)?
Alternatiely, one could simply document the problem in install.texi and be done
with it.
Thoughts?
Rainer
