Re: Please reenable GCJ on mips
Daniel Jacobowitz wrote:
> It's a lot of work to fix and no one has done it. That's not the same
> thing at all.
That's nice, but there's still a real problem unrelated to that.
An example of a relatively healthy bug which is "a lot of work to fix and no
one has done it" is http://gcc.gnu.org/bugzilla/show_bug.cgi?id=6257, the
problem of distinguishing between #include <cstdio> and #include <stdio.h> in
C++ programs and getting the collection of included symbols correct for both
cases. There's a fairly substantial amount of information on the problems
and attempted solutions.
Another example is http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5911 -- the
screwball way Ada is built in GCC -- where the work to fix it is totally
straightforward, but very large and very tedious.
What I keep hearing is that no one has reported the bug(s), and nobody except
Thiemo Seufer has even described it/them adequately. This is a bug or bugs
which is not documented in the documentation or bug databases for glibc,
binutils, gcc, Debian, or anywhere else. It's apparently a substantial and
reproducible bug which hits any library or executable with really large
numbers of exported symbols. The GCC documentation suggests a fix (xgot)
which doesn't actually work.
That is bad.
* Either ld or gcc (or both) should note in its documentation that xgot is
incompatible with multigot. Alternatively, there should be a bug report
against ld because of this. I haven't determined which is considered correct
yet.
* The failure of multigot to support >16K of exported symbols is a bug
somewhere, but I'm still not clear whether it's an ABI limitation or or a bug
in the dynamic linker. If the latter, it needs to be reported. If the
former, it needs to be documented.
Now, I understand this sort of stuff not being dealt with for a while. But
the nature of the problem has supposedly been known for a year or more, and
so a little documentation of "known limitations" is really the least I'd
expect.
m68k is known to be in a situation where serious toolchain bugs are not
reported upstream. I thought previously that it was the only such
architecture.
Reply to: