Ken Murchison wrote:
>
> Olaf Zaplinski wrote:
>
>>Clifford Thurber wrote:
>>
>>>What do you mean when you say they don't disappear? Can you be more
>>>specific?
>>
>>Yes, right now I have 5 processes named 'imapd -s' and 2 named 'lmtp' in my
>>process list. They will stay there forever until I
Olaf Zaplinski wrote:
>
> Clifford Thurber wrote:
> > What do you mean when you say they don't disappear? Can you be more
> > specific?
>
> Yes, right now I have 5 processes named 'imapd -s' and 2 named 'lmtp' in my
> process list. They will stay there forever until I restart cyrus-imapd. And
Clifford Thurber wrote:
> What do you mean when you say they don't disappear? Can you be more
> specific?
Yes, right now I have 5 processes named 'imapd -s' and 2 named 'lmtp' in my
process list. They will stay there forever until I restart cyrus-imapd. And
when the first user logons after tha
Now it works - in /usr/include, I had to delete db.h and the db3 directory.
But my problem is not resolved: I still have several imapd and sometimes one
or more lmtp processes which never disappear.
Olaf
PROTECTED]
Subject: RE: bug in imapd-2.1.3 / Berkeley DB
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 wa
>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:
uot;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]
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/20
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 anyt
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 drov
Hi,
I'm using cyrus-imapd-2.1.3, cyrus-sasl-2.1.1 with db-4.0.14 and
everything works fine now.
First I had a similar problem, which I fixed by linking the new db-lib
from /usr/local/BerkeleyDB.4.0/lib/ to /usr/lib/ . I also replaced the
/usr/include/db*.h files with the new one, because db4 is
Hi Prune,
Prune wrote:
> can you add the result of the 'configure' ? look at the begining when it
> tests for gcc
do you mean this?
checking whether the C compiler (gcc -I/usr/local/BerkeleyDB.3.3/include
-L/usr/local/BerkeleyDB.3.3/lib) works... yes
checking whether the C compiler (gcc -I/us
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:
g
Hi!
Yesterday, I delete a Mailbox (not user.*). This mailbox had set a quota
and after I create a new box with the same name the quota was back.
Is this ok?
Today a remove the quota-entry manual from the quotafile, but it was not
a solution.
Can anybody help me and say what is my problem. I use C
14 matches
Mail list logo
