On Wed, 18 May 2011, Joseph S. Myers wrote: > On Wed, 18 May 2011, DJ Delorie wrote: > > > At this point, though, I'm tempted to say "there's no such thing as a > > target libiberty" and rip all the target-libiberty rules out, and let > > Yes please. I've been arguing for that for some time. > > http://gcc.gnu.org/ml/gcc/2009-04/msg00410.html > http://gcc.gnu.org/ml/gcc/2010-03/msg00002.html > http://gcc.gnu.org/ml/gcc/2010-03/msg00012.html > http://gcc.gnu.org/ml/gcc-patches/2010-12/msg01231.html > http://gcc.gnu.org/ml/gcc-bugs/2011-03/msg00206.html > http://gcc.gnu.org/ml/gcc/2011-03/msg00465.html > http://gcc.gnu.org/ml/gcc-patches/2011-03/msg02304.html
I thought you had the ball on this, but I don't see anything happened since the above was written. I could just add clauses for my own targets, but I want this to happen, so I'll pick it up if it's on the floor. It seems none in approval capacity have any objection to (figuratively) s/target-libiberty//g in toplevel/configure.ac on all branches. Is an --enable-target-libiberty or --with-target-libiberty needed? (I'd just rather not.) What would be an approvable test procedure? Is it enough to test it on native x86_64-linux and cris-axis-elf (a newlib target) with old and new/breaking newlib? At a glance this would partially fix PR47836, and completely fix PR23656, PR47733, PR49247. brgds, H-P
