Re: Linking imapd with db-4.1.25
QUESTION: Does the Berkeley 4.1.25 database not like the version of POSIX threads in Linux Mandrake 9.1, but is happy with the NGPT in Redhat 9.0? I ask because when I built Cyrus-IMAP 2.1.12 against the db4.1 libs on Mandrake 9.1, I ran into the problem described below: / On a Mandrkake 9.1 installation on a Athlon system, I configured Berkely db-4.1.25NC like so, all on one line: env LDFLAGS=-lpthread ../dist/configure --enable-posixmutexes --enable-cxx --enable-test --enable-rpc --enable-tcl -with-tcl=/usr/lib --prefix=/usr I noticed this in the output of configure, though: ./build_unix/config.log:configure:17731: result: POSIX/pthreads/private And subsequently, my build of cyrus-IMAP 2.1.13 linked against this db-4.1.25, yielded these messages in /var/log/syslog when I started: Jun 10 17:25:49 ns1 ctl_cyrusdb[10682]: recovering cyrus databases Jun 10 17:25:49 ns1 ctl_cyrusdb[10682]: DBERROR db4: Berkeley DB library configured to support only DB_PRIVATE environments Jun 10 17:25:49 ns1 ctl_cyrusdb[10682]: DBERROR: dbenv-open '/var/lib/imap/db' failed: Invalid argument Looking through the changelog for Berkeley DB 4.1.24, I found: 2. Support configuration of POSIX pthread mutexes on systems where the pthread mutexes do not support inter-process locks. [#4942] And then in the Berkeley DB Reference Guide, there is: DB_PRIVATE Specify that the environment will only be accessed by a single process (although that process may be multithreaded). This flag has two effects on the Berkeley DB environment. First, all underlying data structures are allocated from per-process memory instead of from shared memory that is potentially accessible to more than a single process. Second, mutexes are only configured to work between threads. This flag should not be specified if more than a single process is accessing the environment because it is likely to cause database corruption and unpredictable behavior. For example, if both a server application and the Berkeley DB utility db_stat are expected to access the environment, the DB_PRIVATE flag should not be specified. -- Scott Langley [EMAIL PROTECTED] Systems Administrator Rural Network Services
Re: Linking imapd with db-4.1.25
On Fri, June 6, 2003 3:28 pm, you wrote: On Fri, June 6, 2003 2:46 pm, John Alton Tamplin wrote: Igor Brezac wrote: This problem is fixed in cvs for both 2.1.x and 2.2. Ok, so it was a problem in Cyrus not db? Thanks. I'm not so sure. Checked 2.1 branch out of CVS and I still can't get it to work. Same results with 2.2-ALPHA. It finds db-4.0 but not db-4.1. Upon further investigation, it looks like maybe the problem is with db-4.1.25 and not cyrus... Here's some output from config.log: snip configure:5808: checking for db_create in -ldb-4.1 configure:5839: gcc -o conftest -Wall -g -O2 -I/usr/local/itech/iwaymail/include -L/usr/local/lib -Wl,-rpath,/usr/local/lib - L/usr/local/itech/iwaymail/lib conftest.c -ldb-4.1 -L/usr/local/itech/iwaymail/lib -lresolv -Wl,-rpath,/usr/local/itech/iw aymail/lib 5 /usr/local/itech/iwaymail/lib/libdb-4.1.so: undefined reference to `pthread_condattr_setpshared' /usr/local/itech/iwaymail/lib/libdb-4.1.so: undefined reference to `pthread_mutexattr_destroy' /usr/local/itech/iwaymail/lib/libdb-4.1.so: undefined reference to `pthread_mutexattr_setpshared' /usr/local/itech/iwaymail/lib/libdb-4.1.so: undefined reference to `pthread_mutexattr_init' /usr/local/itech/iwaymail/lib/libdb-4.1.so: undefined reference to `pthread_mutex_trylock' collect2: ld returned 1 exit status configure:5842: $? = 1 snip Any ideas where I might find some support for db-4.1.25? Can't find any mailing lists or news feeds on sleepycat's site. Lars I finally figured out how to get cyrus-imapd linked up with my 4.1.25 on RedHat 9. You need to add -lpthread to LDFLAGS (and export it to the environment) before running the configure script. I don't know who's job it should be to figure out that additional linker flag...the addition of nptl in RedHat 9 is turning out to be really problematic thus far. Lars
Linking imapd with db-4.1.25
Hello, I've built and installed db-4.1.25 in a non-standard location on my RedHat 9.0 machine and am having trouble getting cyrus-imapd-2.1.13 to against it. It appears that the configure script does not detect it properly, even if I invoke the configure script with the --with-bdb-libdir=my non-standard db-4.1.25 location and --with-bdb-incdir=my non standard db-4.1.25 location options set. Snippet from configure's output: === checking for db.h... yes checking for db_create in -ldb-4.1... no checking for db_create in -ldb4.1... no checking for db_create in -ldb41... no checking for db_create in -ldb-4.0... yes === When I do an ldd on the resultant imapd binary after the build finishes, I see that it been linked to the bdb libraries that came with the RedHat install (4.0.14-20). I've played around with LDFLAGS, CPPFLAGS, and LD_LIBRARY_PATH environment variables to try and force the directories of my non-standard libraries and headers to be loaded first, but that didn't change a thing. I'm reluctant to remove the RedHat db4 installation because I quite certain that it would break a large amount of dependencies... Any ideas? Thanks, Lars Peterson iTech Inc.
Re: Linking imapd with db-4.1.25
Lars Peterson wrote: Snippet from configure's output: === checking for db.h... yes checking for db_create in -ldb-4.1... no checking for db_create in -ldb4.1... no checking for db_create in -ldb41... no checking for db_create in -ldb-4.0... yes === When I do an ldd on the resultant imapd binary after the build finishes, I see that it been linked to the bdb libraries that came with the RedHat install (4.0.14-20). I've played around with LDFLAGS, CPPFLAGS, and LD_LIBRARY_PATH environment variables to try and force the directories of my non-standard libraries and headers to be loaded first, but that didn't change a thing. I'm reluctant to remove the RedHat db4 installation because I quite certain that it would break a large amount of dependencies... Any ideas? In the directory you passed for bdb-libdir, is there a libdb-4.1.so? Are permissions on it set properly? BTW, you may be happier using 4.0.14. On Solaris anyway, I consistently ran into problems after a week or two of uptime with 4.1.25, and that all went away after downgrading to 4.0.14. -- John A. Tamplin Unix System Administrator Emory University, School of Public Health +1 404/727-9931
Re: Linking imapd with db-4.1.25
On Fri, June 6, 2003 2:05 pm, John Alton Tamplin wrote: Lars Peterson wrote: Snippet from configure's output: === checking for db.h... yes checking for db_create in -ldb-4.1... no checking for db_create in -ldb4.1... no checking for db_create in -ldb41... no checking for db_create in -ldb-4.0... yes === When I do an ldd on the resultant imapd binary after the build finishes, I see that it been linked to the bdb libraries that came with the RedHat install (4.0.14-20). I've played around with LDFLAGS, CPPFLAGS, and LD_LIBRARY_PATH environment variables to try and force the directories of my non-standard libraries and headers to be loaded first, but that didn't change a thing. I'm reluctant to remove the RedHat db4 installation because I quite certain that it would break a large amount of dependencies... Any ideas? In the directory you passed for bdb-libdir, is there a libdb-4.1.so? Are permissions on it set properly? Yes libdb-4.1.so is in the same directory I passed to configure for bdb-libdir. Permissions are same user I'm building as, and mode is 775. I was able to link against these libraries successfully for an openldap-2.1.19 build. BTW, you may be happier using 4.0.14. On Solaris anyway, I consistently ran into problems after a week or two of uptime with 4.1.25, and that all went away after downgrading to 4.0.14. I'll take this into consideration. I've had no problems thus far with db-4.1.25 with respect to openldap / slapd... What kind of problems were you seeing on your Solaris box? Lars
Re: Linking imapd with db-4.1.25
On Fri, 6 Jun 2003, John Alton Tamplin wrote: Lars Peterson wrote: Snippet from configure's output: === checking for db.h... yes checking for db_create in -ldb-4.1... no checking for db_create in -ldb4.1... no checking for db_create in -ldb41... no checking for db_create in -ldb-4.0... yes === When I do an ldd on the resultant imapd binary after the build finishes, I see that it been linked to the bdb libraries that came with the RedHat install (4.0.14-20). I've played around with LDFLAGS, CPPFLAGS, and LD_LIBRARY_PATH environment variables to try and force the directories of my non-standard libraries and headers to be loaded first, but that didn't change a thing. I'm reluctant to remove the RedHat db4 installation because I quite certain that it would break a large amount of dependencies... Any ideas? In the directory you passed for bdb-libdir, is there a libdb-4.1.so? Are permissions on it set properly? BTW, you may be happier using 4.0.14. On Solaris anyway, I consistently ran into problems after a week or two of uptime with 4.1.25, and that all went away after downgrading to 4.0.14. This problem is fixed in cvs for both 2.1.x and 2.2. -- Igor
Re: Linking imapd with db-4.1.25
Lars Peterson wrote: Yes libdb-4.1.so is in the same directory I passed to configure for bdb-libdir. Permissions are same user I'm building as, and mode is 775. I was able to link against these libraries successfully for an openldap-2.1.19 build. Then I suggest looking at the log generated by configure and see why it didn't think it passed the test. I'll take this into consideration. I've had no problems thus far with db-4.1.25 with respect to openldap / slapd... Right, I haven't had any problems in any other application either. I don't know if that is because they don't get as heavy usage or if the usage pattern is different or what. What kind of problems were you seeing on your Solaris box? After a week or two of uptime, I would get ENOSPC returns from dbopen, and sieve would stop working (since my duplicate delivery database is using db3_nosync). Other people reported similar problems with 4.1.24-25 in this list without any resolution, until someone suggested to me that going back to db 4.0.14 would fix the problem. -- John A. Tamplin Unix System Administrator Emory University, School of Public Health +1 404/727-9931
Re: Linking imapd with db-4.1.25
Igor Brezac wrote: This problem is fixed in cvs for both 2.1.x and 2.2. Ok, so it was a problem in Cyrus not db? Thanks. -- John A. Tamplin Unix System Administrator Emory University, School of Public Health +1 404/727-9931
Re: Linking imapd with db-4.1.25
On Fri, June 6, 2003 2:46 pm, John Alton Tamplin wrote: Igor Brezac wrote: This problem is fixed in cvs for both 2.1.x and 2.2. Ok, so it was a problem in Cyrus not db? Thanks. I'm not so sure. Checked 2.1 branch out of CVS and I still can't get it to work. Same results with 2.2-ALPHA. It finds db-4.0 but not db-4.1. Upon further investigation, it looks like maybe the problem is with db-4.1.25 and not cyrus... Here's some output from config.log: snip configure:5808: checking for db_create in -ldb-4.1 configure:5839: gcc -o conftest -Wall -g -O2 -I/usr/local/itech/iwaymail/include -L/usr/local/lib -Wl,-rpath,/usr/local/lib - L/usr/local/itech/iwaymail/lib conftest.c -ldb-4.1 -L/usr/local/itech/iwaymail/lib -lresolv -Wl,-rpath,/usr/local/itech/iw aymail/lib 5 /usr/local/itech/iwaymail/lib/libdb-4.1.so: undefined reference to `pthread_condattr_setpshared' /usr/local/itech/iwaymail/lib/libdb-4.1.so: undefined reference to `pthread_mutexattr_destroy' /usr/local/itech/iwaymail/lib/libdb-4.1.so: undefined reference to `pthread_mutexattr_setpshared' /usr/local/itech/iwaymail/lib/libdb-4.1.so: undefined reference to `pthread_mutexattr_init' /usr/local/itech/iwaymail/lib/libdb-4.1.so: undefined reference to `pthread_mutex_trylock' collect2: ld returned 1 exit status configure:5842: $? = 1 snip Any ideas where I might find some support for db-4.1.25? Can't find any mailing lists or news feeds on sleepycat's site. Lars
Re: Linking imapd with db-4.1.25
Lars Peterson wrote: Here's some output from config.log: snip configure:5808: checking for db_create in -ldb-4.1 configure:5839: gcc -o conftest -Wall -g -O2 -I/usr/local/itech/iwaymail/include -L/usr/local/lib -Wl,-rpath,/usr/local/lib - L/usr/local/itech/iwaymail/lib conftest.c -ldb-4.1 -L/usr/local/itech/iwaymail/lib -lresolv -Wl,-rpath,/usr/local/itech/iw aymail/lib 5 /usr/local/itech/iwaymail/lib/libdb-4.1.so: undefined reference to `pthread_condattr_setpshared' /usr/local/itech/iwaymail/lib/libdb-4.1.so: undefined reference to `pthread_mutexattr_destroy' /usr/local/itech/iwaymail/lib/libdb-4.1.so: undefined reference to `pthread_mutexattr_setpshared' /usr/local/itech/iwaymail/lib/libdb-4.1.so: undefined reference to `pthread_mutexattr_init' /usr/local/itech/iwaymail/lib/libdb-4.1.so: undefined reference to `pthread_mutex_trylock' collect2: ld returned 1 exit status configure:5842: $? = 1 snip Any ideas where I might find some support for db-4.1.25? Can't find any mailing lists or news feeds on sleepycat's site. Ah, you are running into fun with RH9's NPTL (New Posix Threads Library). If you look at the archives for this list you will find some discussion about it. I believe the quick and dirty solution was to compile DB4 with a flag telling it to assume phtreads were not available, but Simon also posted a link to a discussion at RedHat about more general issues with NPTL. The particular errors you are getting are because it can't find the pthreads library when it does the test. You can fix that by telling configure to use -lpthreads on any compiles, but if I remember correctly you will then run into other issues when DB4 tries to do some operations on the threads. I am staying with RH8 for my production machines because of this and a few other minor issues. -- John A. Tamplin Unix System Administrator Emory University, School of Public Health +1 404/727-9931
Re: Linking imapd with db-4.1.25
On Fri, 6 Jun 2003, John Alton Tamplin wrote: Igor Brezac wrote: This problem is fixed in cvs for both 2.1.x and 2.2. Ok, so it was a problem in Cyrus not db? Thanks. This is an unfortunate bug. Sleepycat added db handle locking in 4.1.25 and cyrus was not closing db handles to clear the locks after the services (lmtpd, imapd...) terminated. -- Igor
