Thus said "Andy Bradford" on 31 Jan 2018 13:26:53 -0700:
I believe the actual nmh port does enable iconv support, so this would
not come out there. It only was detected because I didn't bother to do
things in the ``standard'' way.
Apparently I did already have libiconv installed, I just assumed I
didn't have it because it was failing. As indicated in my previous
email, apparently configure is not detecting it.
Also, what's interesting is that apparently while my locally built nmh
doesn't have iconv, apparently the one built from ports does:
$ ldd uip/mhshow
uip/mhshow:
Start End Type Open Ref GrpRef Name
19619000 3962f000 exe 1 0 0 uip/mhshow
0f939000 2f951000 rlib 0 1 0 /usr/lib/libtermcap.so.14.0
094de000 29507000 rlib 0 1 0 /usr/lib/libc.so.89.3
0726d000 0726d000 rtld 0 1 0 /usr/libexec/ld.so
$ ldd /usr/local/bin/mhshow
/usr/local/bin/mhshow:
Start End Type Open Ref GrpRef Name
19629000 3963c000 exe 1 0 0 /usr/local/bin/mhshow
02c5b000 22c73000 rlib 0 1 0 /usr/lib/libtermcap.so.14.0
0d635000 2d715000 rlib 0 1 0 /usr/local/lib/libiconv.so.6.0
0a9c1000 2a9ea000 rlib 0 1 0 /usr/lib/libc.so.89.3
05527000 05527000 rtld 0 1 0 /usr/libexec/ld.so
So it's interesting that even though I have libiconv installed, when I
build as indicated, I don't get iconv support linked in, but somehow the
port did (perhaps due to the LIB_DEPENDS) as mentioned previously.
Which means that when building from ports, nmh will have iconv, but when
building stand-alone, it will not (given that it couldn't find iconv.h).
Of course, all of this does not eliminate the problem of the test not
working correctly when ICONV_ENABLED=0.
Thanks,
Andy
--
TAI64 timestamp: 400000005a722bd7
--
Nmh-workers
https://lists.nongnu.org/mailman/listinfo/nmh-workers