armv4l bootstrap problem in libstdc++-v3

[Richard Earnshaw]

> Isn't the cause of this problem the one that I outlined in my post
> last month:
> 
>   http://gcc.gnu.org/ml/gcc-bugs/2000-12/msg00461.html

Yes, but it would appear that that wasn't acceptable to the C++ 
maintainers.

> There has been some discussion by the C++ guys, but I do not know if a
> fix was ever committed to the sources.  My post did contain a
> workaround, but that was never applied either.

Indeed.  I cannot force someone else to fix the problem, and if they won't 
accept your patch either, there is very little I can do at this point in 
time  -- I have neither the knowledge to fix the problem quickly nor the 
time to work out what would need to be done to fix it along the lines 
suggested.

Most importantly I don't believe we can leave the ARM tree in a 
non-bootable state any longer, give the impending release -- we really 
need to test and fix other things, which isn't possible if the C++ 
libraries won't build out of the box.  I'm disappointed that it has come 
to this, but it is out of my control.

> : I have tried to produce, but have been unsuccessful, a test case which 
> : causes a similar problem with one of the standard built-ins.  This 
> : probably means I still don't fully understand the failure fully.
> 
> In theory any builtin which has a type of "void (char *)" should
> trigger this problem.  Or in fact any backend created builtin with a
> type that matches the type of a C++ builtin function.

Unfortunately, no other port has a builtin with that signature, and when I 
attempted to build a test case with the same signature as say, ffs or 
memcopy, the code compiled correctly.  So I've either mis-understood the 
problem, or I've missed something subtle.  If someone can devise a test 
case that demonstrates the bug, that would be ideal -- we could then check 
it into the test suite and the automated test system could whinge about it 
until it were fixed.

R.