On Sat, 27 Dec 2008, I wrote: > So it looks like this case needs to be refined, not to reject uClibc, but > to make sure the platform is indeed ELF, which is no longer implied by > "__GLIBC__".
I looked a little more closely and it seems things are a bit wierd. The code in question is already wrapped within an "#if defined(OBJECT_FORMAT_ELF)" block. Maybe multiple fixes for the same problem got committed at once? If so, then it makes sense to dike the __UCLIBC__ check since it is overbroad compared to the ELF format check. BTW, the page you linked asserts that uClibc doesn't have EH_FRAME support yet on the grounds that PT_GNU_EH_FRAME is not mentioned in the uClibc source, except in the <elf.h> header. That's not how it works -- ld.so does not need to parse the segment itself -- all it needs to do is tell libgcc_s.so where all the segments are. libgcc_s.so then sifts out the PT_GNU_EH_FRAME ones and parses them on its own. My own testing proves the basic machinery works, despite uClibc's PT_GNU_EH_FRAME agnosticism. But the reason I asked here is that there might be some subtle case that doesn't work. ---- Michael Deutschmann <[email protected]> _______________________________________________ uClibc mailing list [email protected] http://lists.busybox.net/mailman/listinfo/uclibc
