Perhaps all this could be made into a nice Linux how to as the current one seems rather dated and doesn't address any of these problems.
At 11:37 AM 3/26/2002 -0500, OCNS Consulting wrote: >Clifford: > >You are correct! The only way I could get Cyrus IMAP 2.1.3 to use the >desired >BDB 4.x header was to replace the BDB 3.x "/usr/include/db.h" header with >(in my case) a sym link from "/usr/localBerkeleyDB.4.0/include/db.h" to -> >"/usr/include/db.h". > >By the way: a similar situation also occurs when configuring Cyrus SASL V2 >libraries. The difference is that SASL looks for directory >"/usr/include/db3". >The "configure script" will always check for this directory and use the >header >file(s) located there - No Matter What is Specified with Option >"--with-bdb-incdir"; >For Instance: > > --with-bdb-incdir=/usr/local/BerkeleyDB.4.0/include > >To ensure that the proper BDB 4.x headers are used when configuring SASL V2, >I >suggest renaming/mv directory "/usr/include/db3" to "/usr/include/db3.SAV" >and >create a sym link from "/usr/local/BerkeleyDB.4.0/include" to >"/usr/include/db3": > > ln -fs /usr/local/BerkeleyDB.4.0/include /usr/include/db3 > >This resolves a Segmentation Fault - Death by 11 headache. > >By the way: you'll need to maintain a version of the BDB 3.x "so" library >i.e. -> > > /lib/libdb-3.3.so > >or the following messages will be logged in the "messages" file when >"master" starts >the child protocol and services servers: > > imapd[2866]: unable to dlopen libsasl.so: libdb-3.3.so: cannot > open shared >object file: No such file or directory > imapd[2867]: unable to dlopen libsasl.so: libdb-3.3.so: cannot > open shared >object file: No such file or directory > pop3d[2869]: unable to dlopen libsasl.so: libdb-3.3.so: cannot > open shared >object file: No such file or directory > pop3d[2868]: unable to dlopen libsasl.so: libdb-3.3.so: cannot > open shared >object file: No such file or directory > lmtpd[2870]: unable to dlopen libsasl.so: libdb-3.3.so: cannot > open shared >object file: No such file or directory > >I don't know what impact this may or may not have but given the reference to >"libsasl" >there appears to be some authentication ramification's). Does anyone know? > >RB > >-----Original Message----- >From: [EMAIL PROTECTED] >[mailto:[EMAIL PROTECTED]]On Behalf Of Clifford >Thurber >Sent: Tuesday, March 26, 2002 10:32 AM >To: Prune >Cc: Olaf Zaplinski; [EMAIL PROTECTED] >Subject: Re: bug in imapd-2.1.3 / Berkeley DB > > >I set every one of these environmental variables and also added the db5.0 >lib to /etc/ld.so.conf and ran ldconfig. None of that matters. It doens't >matter as the linker will always look in /usr/include first and grab what >is there. The only way is to replace that db.h file. > >At 04:14 PM 3/26/2002 +0100, Prune wrote: > >Clifford Thurber wrote: > > > >>You are most likely compiling this on a linux system. This happens > >>because of /usr/include/db.h. This is the header fileshipped witht the > >>distro. Cyrus will compile using your CFLAGS below but the linker will > >>use the db.h file under /usr/include. I think if anything this is a linux > >>bug. It drove me nuts for a few days. I ended up using the db libs that > >>Red Hat ships with. > > > >linux : 1 > >you : 0 > > > >try to set LDFLAGS, CPPFLAGS, CFLAGS, LD_RUN_PATH and LD_LIBRARY_PATH. > >Il this fail, rm the Linux db.h !! > > > >if all fail, install FreeBSD or Solaris. > > > >Cheers, > > > >prune > > > >> > >>At 09:26 AM 3/26/2002 +0100, Olaf Zaplinski wrote: > >> > >>>Hi *, > >>> > >>>following bug occured: > >>> > >>>1. > >>>CPPFLAGS=-I/usr/local/BerkeleyDB.3.3/include \ > >>>LDFLAGS=-L/usr/local/BerkeleyDB.3.3/lib \ > >>>./configure > >>> > >>>2. > >>>make > >>> > >>>3. > >>>make install > >>> > >>>4. > >>>start of cyrus => 'incorrect version of Berkeley db: compiled against > >>>3.1.17, linked against 3.3.11' > >>> > >>>So I re-started 3. and voila: > >>>gcc -c -I/usr/include/db3 -I/usr/local/BerkeleyDB.3.3/include [...] > >>> > >>>Although I told configure where to look for db3, it searches on its own >and > >>>finds the system's db-3.1.17 instead of by self built db-3.3.11. > >>> > >>>Workaround: vi `find . -name Makefile` :-( > >>>(This did not really help because sasl-2.1.1 does not like db-3.3, > >>>saslpasswd2 crashes.) > >>> > >>>Regards > >>>Olaf > >>> > > > >
