On Mon, Jul 28, 2014 at 12:36:21PM -0700, Roland McGrath wrote: > This is definitely not going to make it into glibc-2.20, so you might want > to wait until we're out of release freeze to worry too much about the > glibc-oriented bits.
That's fine. I figured the patch wasn't 2.20 material. I copied the series to libc-alpha because patch 4/5 touches rather a lot of glibc specific support, and I'd already posted a previous attempt to libc-alpha to explore the possibility of switching to using size_t without bumping __OBSTACK_INTERFACE_VERSION. > Meanwhile, you can iron out your other cleanups with > gnulib folks. > > For glibc you need to do some more work to make the provision of > compatibility symbols clean. The entire compatibility build needs > to be protected with a SHLIB_COMPAT test. The compatibility symbols > need to be made unavailable at link time, using versioned_symbol macros. Yes, I realised this after posting the patch. I'm starting to question my sanity in attempting to fix this obstack problem properly. It would have been so much easier to just fix the gdb bug I ran into: https://sourceware.org/bugzilla/show_bug.cgi?id=17133 Oh well. At least I have a working knowledge of glibc internals that makes it reasonably easy to fix the compat issue. BTW, this obstack problem has been known since at least 2007, and I suspect the main reason it has remained unfixed is the number of hoops that need to be negotiated before a patch can be committed.. It's not just gnulib and glibc, but eg. to update the ancient obstack.h in libiberty, gcc, gdb and gas all needed fixes to remove improper use of obstack internals. https://sourceware.org/bugzilla/show_bug.cgi?id=14483 https://bugzilla.redhat.com/show_bug.cgi?id=231832 -- Alan Modra Australia Development Lab, IBM
