About a week ago, src/lib/libc/locale/nl_langinfo.c in RELENG_4 received an update from 1.13.2.2 to 1.13.2.3, which added nl_langinfo to RELENG_4's libc.
I have no problem with that at all. :-) However, the symbol in question does not appear to exist in the version of libc.so.4 in -CURRENT's /usr/lib/compat -- and that can cause programs which had been compiled under -STABLE and which might well otherwise work Just Fine under -CURRENT to fail, thus: freebeast(5.0-C)[8] screen /usr/libexec/ld-elf.so.1: screen: Undefined symbol "nl_langinfo" freebeast(5.0-C)[9] In this particular case, I've been working around the nuisance by merely recompiling a "-CURRENT-private" version of screen (on each of my build machine & laptop). I'm rather less eager to do this for, say, mozilla (for example).... What is the procedure for getting /usr/lib/compat/libc.so.4 updated to include nl_langinfo (and, perhaps, other symbols that might be in -STABLE's /usr/lib/libc.so.4)? [Were this strictly a -STABLE issue, I'd file a PR. But for -CURRENT, things seem to be sufficiently fluid that the additional overhead of dealing with a PR appears (to me) to be just that -- additional overhead. And it's not a problem that manifests itself as a "problem with/running -STABLE" -- it bites someone running -CURRENT, who is supposed to have some minimal level of clue....] Sorry about the lack of attached patch; I'm not (yet) clear on how compat/libc.so.4 get built.... :-( Thanks, david -- David H. Wolfskill [EMAIL PROTECTED] I believe it would be irresponsible (and thus, unethical) for me to advise, recommend, or support the use of any product that is or depends on any Microsoft product for any purpose other than personal amusement. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
