So I ran imtest in gdb to see where it was
segfaulting, and I got:
(gdb) where
#0 0x0 in ?? ()
#1 0x402f4ae2 in __db_err () from /lib/libdb.so.3
#2 0x402ee23d in db_open () from /lib/libdb.so.3
#3 0x402d7d0a in _nss_db_getprotobynumber_r () from /lib/libnss_db.so.2
#4 0x402d7efa in _nss_db_endservent () from /lib/libnss_db.so.2
#5 0x402d8181 in _nss_db_getservbyname_r () from /lib/libnss_db.so.2
#6 0x401c1fe1 in getservbyname_r () from /lib/libc.so.6
#7 0x401c1ea1 in getservbyname () from /lib/libc.so.6
#8 0x8053603 in strcpy ()
#9 0x4012aa52 in __libc_start_main () from /lib/libc.so.6
so we appear to have some conflicting db routines.
my roomate observed that this was all happening
before the imtest code even started running, and sure
enough, I had "db" as an option in my nsswitch.conf file
for protocols, services, ethers, and rpc. Since I fortunately
do not use db's for any of those lookups, I simply removed
the "db" entries from the file and imtest starting working,
which is to say failing to successfully authenticate in the
same manner that telnet'ing to the imap port fails...
I do have a theoretical question here,
where my knowledge of how linux dynamic linkers work fails:
is there a way to build imtest such that when libnss_db.so needs db functions,
it gets versions it can use
(I'm assuming it needs the version it was built against, 2.1.3),
but imtest can still get the versions of the db functions _it_ needs
(version 3 or better),
or does this really require rebuilding libnss_db.so against
the same db version as imtest?
if I don't figure out the sasl stuff in the next day or two, I'll send
mail describing the weird stuff I'm seeing (sasl sample-client and
sample-server work fine, but the imap server won't allow LOGIN or AUTH
PLAIN) and beg for more help...
--akb
