mbrlen() vs. compatibility with -STABLE-compiled ports

Perhaps it's unrealistic to expect this to work, but on each of the
machines where I run -CURRENT, I also run -STABLE (on other slices),
but I generally only build ports under -STABLE, and /usr/local is
common to both the -CURRENT and -STABLE environments.  (I build -CURRENT
with "COMPAT4X= yes" specified in /etc/make.conf.)

And in practice, this has generally worked rather well (with only a
couple of exceptions over the couple of years I've been doing this),
while I've been tracking each of -STABLE and -CURRENT (and doing a
"portupgrade -a" under -STABLE) on a daily basis.  Thus, I had some
reason to believe that the setup was testing how well the compatibility
code was working.

After recovering from a series of misadventures (-CURRENT challenges
from recent statfs changes; hardware issues on the machines [warranty
repair for the laptop; reset BIOS to get proper CPU timing on the SMP
"build" machine]), I think my environment is back to what passes for
"normal" around here:  I was able to build today's -CURRENT OK while
running yesterday's -CURRENT in multi-user mode (in the case of the
laptop, while running X; the build machine generally runs headless).

And I apologize:  this turned out to be rather longer than I intended.

Since -CURRENT is now 5.2-BETA, I thought it might be worth reporting
what appears to be a problem with the compatibility code.  I am,
however, no expert on the mechanisms by which this works, so I'll try to
confine my comments to what I actually observe (and immediately-derivable 
conclusions).

First, a little more background:  I recently had occasion to augment my
collection of installed ports to include mod_php4-4.3.4_2,1.  (I run the
apache-1.3.29_1 Web server on each of the machines in question.)  As
mentioned above, this was built under -STABLE.  And it appears to work.

When I boot -CURRENT:
g1-15(5.2)[5] uname -a
FreeBSD g1-15.catwhisker.org 5.2-BETA FreeBSD 5.2-BETA #1: Sun Nov 23 11:49:39 PST 2003     root_at_g1-15.catwhisker.org:/common/S2/obj/usr/src/sys/LAPTOP_30W  i386
g1-15(5.2)[6] 

I see in the console log:

Nov 23 15:11:53 localhost kernel: Starting cron.
Nov 23 15:11:53 localhost kernel: Local package initialization:
Nov 23 15:11:53 localhost kernel: Setting the mixer vol from 75:75 to 25:25.
Nov 23 15:11:54 localhost kernel: Syntax error on line 237 of /usr/local/etc/apache/httpd.conf:
Nov 23 15:11:54 localhost kernel: Cannot load /usr/local/libexec/apache/libphp4.so into server: /usr/lib/libhistory.so.4: Undefined symbol "mbrlen"
Nov 23 15:11:54 localhost kernel: Starting snmpd.
Nov 23 15:12:16 localhost kernel: .

The message in question is the whine about mbrlen().

I'll point out now (in case it isn't obvious) that when this set of messages
is issued, apache does not start.

As to the cause of the whine:

g1-15(5.2)[4] ls -l libhistory* compat/libhist*
-r--r--r--  1 root  wheel  20351 Nov 23 12:25 compat/libhistory.so.3
-r--r--r--  1 root  wheel  31362 Nov 23 12:27 libhistory.a
lrwxrwxr-x  1 root  wheel     15 Nov 23 12:27 libhistory.so -> libhistory.so.4
-r--r--r--  1 root  wheel  25156 Nov 23 12:27 libhistory.so.4
-r--r--r--  1 root  wheel  32234 Nov 23 12:27 libhistory_p.a
g1-15(5.2)[5] nm -D libhistory.so.4 | grep -iC mbrlen
         U malloc
00006d7c B max_input_history
         U mbrlen
         U mbrtowc
00005190 T next_history
g1-15(5.2)[6] nm -D libc.so  | grep -iC mbrlen
0003a3b0 T mblen
0003a2b0 T mbmb
00053230 T mbrlen
0003a230 T mbrrune
0009b6f0 T mbrtowc
g1-15(5.2)[7] 

The above is from the usual -CURRENT environment.  Now, comparing that
with -STABLE:

g1-15(5.2)[1] sudo mount -o ro /S1
Password:
g1-15(5.2)[2] sudo mount -o ro /S1/usr
g1-15(5.2)[3] cd !$/lib
cd /S1/usr/lib
g1-15(5.2)[4] ls -l libhistory* compat/libhist*
-r--r--r--  1 root  wheel  20351 Nov 23 07:29 compat/libhistory.so.3
-r--r--r--  1 root  wheel  24518 Nov 23 07:30 libhistory.a
lrwxrwxr-x  1 root  wheel     15 Nov 23 07:30 libhistory.so -> libhistory.so.4
-r--r--r--  1 root  wheel  19452 Nov 23 07:30 libhistory.so.4
-r--r--r--  1 root  wheel  26520 Nov 23 07:30 libhistory_p.a
g1-15(5.2)[5] nm -D libhistory.so.4 | grep -iC mbrlen
g1-15(5.2)[6] nm -D libc.so.4  | grep -iC mbrlen
g1-15(5.2)[7] 

We see that libc.so.4 does not have mbrlen(), but libc.so.5 does.  So
far, so good.

Also, libhistory.so.4 built under -CURRENT contains a reference to mbrlen(),
while libhistory.so.4 built under -STABLE does not.  Since -STABLE's libc
doesn't have a mbrlen(), but -CURRENT's does, that makes a certain amount
of sense; on the other hand, in some cases (such as the present instance)
this causes a problem.

As I built apache under -STABLE, it references libc.so.4:

g1-15(5.2)[8] ldd `which httpd`
/usr/local/sbin/httpd:
        libcrypt.so.2 => /lib/libcrypt.so.2 (0x280a1000)
        libexpat.so.4 => /usr/local/lib/libexpat.so.4 (0x280ba000)
        libc.so.4 => /usr/lib/compat/libc.so.4 (0x280d6000)
g1-15(5.2)[9] 

so when run under -CURRENT, it is the "compatibility" version of
libc.so.4 that is used (as expected).  And since it is intended to
be equivalent to -STABLE's libc.so.4, it does not (and should not)
have an implementation of mbrlen() in it.

But libhistory.so.4 has the same name under each of -STABLE and -CURRENT,
but the implementation differs:  it is only the latter's that has the
reference to mbrlen().

So it would seem that something needs to give.  As noted above, I don't
know that "bumping" libhistory.so would address the issue such that this
would work.  But until something is done so that it works, maybe folks
just need to be aware of it and take appropriate evasive action.

Peace,
david
-- 
David H. Wolfskill				david_at_catwhisker.org
If you want true virus-protection for your PC, install a non-Microsoft OS
on it.  Plausible candidates include FreeBSD, Linux, NetBSD, OpenBSD, and
Solaris (in alphabetical order).