So, I recently test compiled the new uClibc-0.9.31, and compared its
symbol table to the old 0.9.30.3. There were lots of changes, most of
which are fine. However, I noticed a couple oddities:
__res_state (added)
__resp (added)
These seem to be added as part of a scheme to allow _res to be
sanely emulated in presence of threading. But my build is not threaded
-- so they are a waste.
capset (removed)
Removing this is the correct thing for me, since my kernel
doesn't support capabilities. But why is capget still in?
ll_tzname_UNKNOWN (added)
ll_tzname_UTC (added)
Looks like someone forgot to add some "static" keywords. These
data items are mentioned in no header. Even their data type is only
defined in the .c file that creates them [libc/misc/time/time.c].
posix_fadvise64 (added)
This doesn't belong in my system since both LFS and Advanced
Realtime are configured out.
Furthermore, while looking at the file that creates this symbol
[libc/sysdeps/linux/i386/posix_fadvise64.S], I noticed some careless
#ifdef use which causes it to be assembled as a single "ret" instruction
in the case that no fadvise syscalls are available and UCLIBC_HAS_STUBS
is not set. The result is a function that returns garbage.
-
On a related note, is there ABI breakage in 0.9.31 aside from dropped
symbols?
I now use uClibc as my host, so rolling over to 0.9.31 would be easier if
the new library can support tools compiled with the old. (But I have plans
to cope if it's not, and have no regrets for choosing that problem over
glibc's symbol versioning bloat.)
---- Michael Deutschmann <mich...@talamasca.ocis.net>
_______________________________________________
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc
