So it’s Christmas day, and I’m skimming through the 32+ MB of logs generated by my elven script and I found some nice nuggets:
Symbol getopt_long@@ (32-bit UNIX System V ABI Intel 80386) present 35 times
/usr/bin/graph
/usr/bin/ebzipinfo
/usr/bin/spline
/usr/bin/double
/usr/bin/uupick
/usr/bin/autotrace
/usr/bin/uustat
/usr/sbin/ndtpd
/usr/bin/ode
/usr/sbin/ndtpcheck
/usr/bin/ebrefile
/usr/bin/uucp
/usr/sbin/ndtpcontrol
/usr/bin/uulog
/usr/sbin/uuxqt
/usr/bin/ebzip
/usr/bin/faad
/usr/bin/lha
/usr/lib/libsox.so.1.0.0
/usr/sbin/uucico
/usr/bin/ebinfo
/usr/sbin/uuconv
/usr/bin/plot
/usr/bin/tek2plot
/usr/lib/libc.so.5
/usr/bin/uuname
/usr/bin/uux
/usr/bin/ebstopcode
/usr/bin/stklos
/usr/bin/cu
/usr/bin/plotfont
/usr/bin/ebfont
/usr/bin/ebunzip
/usr/bin/pic2plot
/usr/sbin/uuchk
Symbol strncasecmp@@ (32-bit UNIX System V ABI Intel 80386) present 5 times
/usr/bin/xpilots
/usr/bin/gargoyle-agility
/usr/lib/libc.so.5
/usr/bin/xedit
/usr/bin/xpilot
Symbol strnlen@@ (32-bit UNIX System V ABI Intel 80386) present 5 times
/usr/bin/tarsync
/usr/lib/libCw.so.1.0.0
/usr/lib/libmba.so.0.9.1
/usr/lib/python2.5/site-packages/numarray/_chararray.so
/usr/bin/linksys-tftp
Symbol stricmp@@ (32-bit UNIX System V ABI Intel 80386) present 5 times
/usr/bin/qemacs
/usr/lib/libraidutil.so.0.0.0
/usr/lib/openbabel/2.2.0/inchiformat.so
/usr/lib/libxerces-c-3.0.so
/usr/lib/libIL.so.1.0.0
Now if you ignore the references to the old compatibility libc.so.5 you can still find that there are quite a few programs that reinvent the wheel, reimplementing some functions that the C library already provides. Now, this would be fine and dandy if the implementation was subtly different, or was done with some particular purpose in mind, like glib’s functions, but I really can’t find the reason for the situation above to happen.
These are usually smaller functions, but still there is no reason for them to be present since anyway it’s more than likely that most of their use is replaced away by the compiler itself; more interesting is their presence in shared objects, since that would interpose around other calls, although this most likely won’t happen on glibc based systems since they provide versioned symbols which wouldn’t then interpose by default. That’s still a problem for *BSD systems though.
This has a much lower priority in my list than identifying all libraries bundled by various packages (even when they cannot be fixed, because they are proprietary or something else), because these are unlikely to turn out being security issues. On the other hand, the idea of doing such pointless duplication of common functions might as well caus security issues to be hidden, for instance if a package was to reimplement mktemp, then it would most likely be a problem.
Anyway for those interested to find out what’s duplicating code in their system, the new hit parade, derived directly from the Bug shows SQLite3 trying to climb up the ladder, together with boehm-gc. Why people can’t understand that there are libraries in the system already?
