IMAPD-2.2 on SuSE Alpha Linux

Mike O'Rourke mike.orourke at op.org
Sat Feb 22 18:02:54 EST 2003


Mike O'Rourke already wrote:

>Hi All,
>
>First of all, thanks to the development team for a _great_ package. I have
>been using it on 3 servers for about two years now.
>
>I am building the (CVS) 2.2 branch (like everybody else, I need virtual
>domain support now.) on SuSE 7.1 Linux for the Alpha processor (glibc
>patched to 2.2.33). I have SASL 2.1.12 and Berkeley DB 4.1.25, and my
>configure command is almost identical to that of the 2.1.x builds on this
>machine (I took out --enable-fulldirhash this time):
>
>export CPPFLAGS='-I/usr/local/BerkeleyDB.4.1/include -I/usr/local/ssl/include'
>export LDFLAGS='-L/usr/local/lib/mysql -L/usr/local/ssl/lib
>-L/usr/local/lib/sas
>l2'
>export LIBS='-lssl -lmysqlclient'
>./configure --with-dbdir=/usr/local/BerkeleyDB.4.1 \
>   --with-bdb-libdir=/usr/local/BerkeleyDB.4.1/lib \
>   --with-bdb-incdir=/usr/local/BerkeleyDB.4.1/include \
>   --with-auth=unix \
>   --with-openssl=/usr/local/ssl \
>   --enable-netscapehack \
>   --with-sasl=/usr/local/lib/sasl2 \
>   --with-staticsasl=/usr/local \
>   --with-perl
>
>The configure and build go along fine, but when I start the server, it
>"hangs" with no output to the logfile. I ran it in gdb, and it is looping
>in the hash_insert ( ) function after being called from config_read. A
>backtrace shows me this:
>(gdb) backtrace
>#0  0x12001c8dc in hash_insert ()
>#1  0x12000747c in config_read (alt_config=0x120032220 "/var/spool/imap")
>      at ../lib/libconfig.c:336
>#2  0x1200078c4 in masterconf_init (ident=0x12000a8b1 "master",
>      alt_config=0x120032220 "/var/spool/imap") at masterconf.c:79
>#3  0x120005928 in main (argc=1, argv=0x11ffff698) at master.c:1358
>#4  0x200003756ac in __libc_start_main () from /lib/libc.so.6.1
>
>the "loop" is thus:
>(gdb) stepi
>0x12001c8d4 in hash_insert ()
>(gdb)
>0x12001c8d8 in hash_insert ()
>(gdb)
>0x12001c8dc in hash_insert ()
>(gdb)
>0x12001c8d4 in hash_insert ()
>(gdb)
>0x12001c8d8 in hash_insert ()
>(gdb)
>0x12001c8dc in hash_insert ()
>
>Some possibly useful variables:
>(gdb) print key
>$1 = 0
>(gdb) print confighash
>$2 = {size = 30, table = 0x1200317d0, pool = 0x120031780}
>(gdb) print data
>$3 = 0
>
>I have tried using Berkeley DB 4.0, but get the same result. I am about to
>try to compile it with the Compaq C compiler (ccc), but I don't expect any
>improvement.
>
>Cyrus-IMAPd-2.1.12 builds and runs fine on this machine. The only
>difference I see is that you have switched from using "hash" to "strhash",
>and using the built-in if it is available, but I do not think my system has
>strhash, so this should not make any difference.
>
>Does anyone have any ideas about a solution, or suggestions as to where I
>might proceed before I wade in deeper into the unknown waters of the Cyrus
>code?
>
>Thanks for any help.
>
>Mike.

After a couple of stratigically placed fprintf's, I determined that the 
function hash_insert () was _never_ being called! I saw where it was 
passing "partition_default" as the key and "/var/spool/imap" as the newval, 
but the fprintf to verify these values that I put immediately after the 
variable declarations in hash.c / hash_insert () never printed anything!

It turns out that mysql (3.23.53 here) has a hash_insert function that 
expects the hash table as the first argument and not the last as in the 
cyrus implementation. Without recompiling mysql to put a fprintf statement 
in it's hash_insert () function, I can't verify that cyrus is trying to use 
that one, but the assumption seems reasonable.

Why do I have "-lmysqlclient" in the $LIBS variable in the first place??? I 
compiled SASL 2.1.12 with mysql support, and cyrus-imapd fails with 
undefined symbols (all from the libmysqlclient) if I do not include it.

Suggestions??

Mike.   





More information about the Info-cyrus mailing list