Kris Kennaway wrote:
libm has been fixed, but there are several other libraries that either
need to get the same treatment or have their major version number
bumped.
See the attached mail.
Kris
Robert has offered to take care of libutil. We need someone to help
figure out the right approach for libncp and libopie. I'm tempted to
just bump their versions, but I'll wait for better wizdom from the
community first. Can anyone comment here?
------------------------------------------------------------------------
I audited the results of my comparison script to look for other cases
of symbols being added to 5.x versions of libraries that have the same
version in 4.x, which do not resolve within this set of common
libraries. Here are the results:
==> Comparing symbols in libisc.so.1
* pselect
Called from evGetNext(), which exists in 4.x's libisc. Perhaps libisc
is not widely used except for BIND applications.
==> Comparing symbols in libm.so.2
* __fpclassifyd
* __fpclassifyf
Used in scalb() and scalf(), which exist on 4.x.
==> Comparing symbols in libncp.so.1
* _getprogname
This is used in 5.x's ncp_getopt() and ncp_error() functions, which
also exist on 4.x.
==> Comparing symbols in libopie.so.2
* __xuname
This is hidded inside the static uname() implementation in
<sys/utsname.h> and is referenced from opieinsecure() and
opienewseed(), which exist on 4.x.
==> Comparing symbols in libutil.so.3
* __pw_scan
This one is OK because it is only used from pw_scan(), which does not
exist on 4.x.
* _time_to_time32
This is called from logout() on 5.x, which is a function also used in
4.x's libutil. For example, the following test application
demonstrates the breakage:
#include <sys/types.h>
#include <libutil.h>
main() {
logout("ttypa");
}
It runs correctly as root on 4.x, but gives the following as root on 5.x:
[EMAIL PROTECTED]:/home/kkenn /tmp/a
/usr/libexec/ld-elf.so.1: /usr/lib/libutil.so.3: Undefined symbol "_time_to_time32"
* mac_free
* mac_from_text
* mac_is_present
* mac_set_proc
These are called from setusercontext(), and might cause runtime
failures if a 4.x binary that uses setusercontext() is run on a 5.x
system that has MAC enabled.
Kris
_______________________________________________
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
