Re: [Dovecot] v2.0.0 released
Le 7 sept. 2010 à 16:16:26, Timo Sirainen a écrit :
On Tue, 2010-09-07 at 15:56 +0200, Axel Luttgens wrote:
+ imap and pop3 processes can now handle multiple connections.
Could someone point to some more info about the above?
Well, I don't necessarily recommend actually using it, but it's
possible:
service imap {
client_limit = maybe a few
service_count = 0
}
service pop3 {
client_limit = maybe a few more than imap
service_count = 0
}
The main problem is that some disk I/O, and especially lock waits, can
hang all other connections running in the same process.
Hello Timo,
Many thanks for your reply.
Here, with dovecot 2.0.2, client_limit seems to default to 1 for services imap
and pop3.
Trying client_limit=10 for imap, I get:
dovecot[46911]: imap(testuser): Error: user testuser: Initialization
failed: Initializing mail storage from mail_location setting failed: mbox: mbox
requires client_limit=1 for service
(yes, still experimenting with mbox format...)
Same kind of error message when client_limit is set to a non-default value for
pop3.
On the other hand, client_limit seems to default to 0 for service lmtp.
Leaving that default yields:
dovecot[46286]: lmtp(46334, testuser): Error: user testuser:
Initialization failed: Initializing mail storage from mail_location setting
failed: mbox: mbox requires client_limit=1 for service
and one needs to define client_limit=1 for lmtp as well.
This behavior seems to have been enforced in mbox-storage.c with
http://hg.dovecot.org/dovecot-2.0/rev/28c3486864f6, and comes with following
comment: /* we can't handle locking related problems. */.
This is thus rather new.
But I couldn't find any information on the list related to those locking
problems.
Is it really needed to be so stringent with mbox format?
Or was it jut intended to be a temporary workaround?
TIA,
Axel
Re: [Dovecot] v2.0.0 released
On Wed, 2010-09-15 at 10:12 +0200, Axel Luttgens wrote: Here, with dovecot 2.0.2, client_limit seems to default to 1 for services imap and pop3. Trying client_limit=10 for imap, I get: dovecot[46911]: imap(testuser): Error: user testuser: Initialization failed: Initializing mail storage from mail_location setting failed: mbox: mbox requires client_limit=1 for service Yes. dovecot[46286]: lmtp(46334, testuser): Error: user testuser: Initialization failed: Initializing mail storage from mail_location setting failed: mbox: mbox requires client_limit=1 for service and one needs to define client_limit=1 for lmtp as well. Yes, this is intentional. client_limit=1 default is good for pop3/imap, but for lmtp and non-mbox format a larger client_limit is better because latency doesn't matter that much. This behavior seems to have been enforced in mbox-storage.c with http://hg.dovecot.org/dovecot-2.0/rev/28c3486864f6, and comes with following comment: /* we can't handle locking related problems. */. This is thus rather new. But I couldn't find any information on the list related to those locking problems. Is it really needed to be so stringent with mbox format? Or was it jut intended to be a temporary workaround? The problem is that with mbox format the mbox file can be locked for a long time. So for example two clients handled by the same process may attempt to write to the same mbox: - Client 1 write-locks mbox file and goes back to ioloop waiting for the message data to arrive. - Ioloop starts handling client 2 connection, which also tries to save message to same mailbox and tries to write-lock the same mbox file. Now the second client keeps blocking on the write-lock and waiting for client 1 to release the lock, but since 1 is handled by the same process, this won't happen. This problem doesn't happen with any other mailbox format. Maybe some day in future there's a way to avoid this by having the code notice early that the mailbox is locked and go back to ioloop instead of block.
Re: [Dovecot] v2.0.0 released
Le 16 août 2010 à 16:49:00, Timo Sirainen a écrit : [...] + imap and pop3 processes can now handle multiple connections. [...] Hello, Could someone point to some more info about the above? I remember Mike's message (November 2009, 11th) as well as Timo's plans (January 2010, 23rd), but couldn't find details about the current status of that feature. TIA, Axel
Re: [Dovecot] v2.0.0 released
On Tue, 2010-09-07 at 15:56 +0200, Axel Luttgens wrote:
+ imap and pop3 processes can now handle multiple connections.
Could someone point to some more info about the above?
Well, I don't necessarily recommend actually using it, but it's
possible:
service imap {
client_limit = maybe a few
service_count = 0
}
service pop3 {
client_limit = maybe a few more than imap
service_count = 0
}
The main problem is that some disk I/O, and especially lock waits, can
hang all other connections running in the same process.
Re: [Dovecot] v2.0.0 released
On Aug 16, 2010, at 7:49 AM, Timo Sirainen wrote: http://dovecot.org/releases/2.0/dovecot-2.0.0.tar.gz http://dovecot.org/releases/2.0/dovecot-2.0.0.tar.gz.sig A new dovecot2 port Mac and/or MacPorts users here. http://trac.macports.org/ticket/26111 Regards, Bradley Giesbrecht
Re: [Dovecot] v2.0.0 released
- Original Message - From: Timo Sirainen t...@iki.fi Date: Monday, August 16, 2010 6:31 pm Subject: Re: [Dovecot] v2.0.0 released Cc: Dovecot Mailing List dovecot@dovecot.org On 16.8.2010, at 23.25, Dennis Clarke wrote: imap-match.c, line 199: identifier redeclared: imap_match_dup I think someone reported this problem earlier .. but I'm not sure. Anyway I've no idea why it would complain about this. So that stops me while I figure out what the issue is with imap-match.h and/or imap-match.c in the Solaris world while using Sun Studio 11. I heard it compiles ok with Sun Studio 12.1. Seems to compile fine with GCC 4.5.1 and binutils 2.20.1.20100303. However the install process then fails repeatedly. Any thoughts on this ? http://www.blastwave.org/docs/dovecot_2.0.0_install-FAIL.txt The same log with numbers lines is here : http://www.blastwave.org/docs/dovecot_2.0.0_install-FAIL-N.txt Where I see on line 354 : libtool: install: ../.././install-sh -c .libs/auth /opt/csw/libexec/dovecot/auth Which sure looks like the file auth being copied into place and then right after we get a failure : libtool: install: ../.././install-sh -c .libs/checkpassword-reply /opt/csw/libexec/dovecot/checkpassword-reply test -z /opt/csw/libexec/dovecot/auth || ../.././install-sh -c -d /opt/csw/libexec/dovecot/auth mkdir: /opt/csw/libexec/dovecot/auth: Exists but is not a directory mkdir: /opt/csw/libexec/dovecot/auth: Exists but is not a directory On line 372 onwards I try again with a whole new compile and install fails again. I think the compile went fine but getting the results into place on the filesystem is turning out to be a real chore. Certainly not make install simple. Dennis
Re: [Dovecot] v2.0.0 released
On Tue, 2010-08-17 at 09:34 -0400, Dennis Clarke wrote: libtool: install: ../.././install-sh -c .libs/auth /opt/csw/libexec/dovecot/auth Which sure looks like the file auth being copied into place Yes, that's correct. and then right after we get a failure : libtool: install: ../.././install-sh -c .libs/checkpassword-reply /opt/csw/libexec/dovecot/checkpassword-reply This is also correct. test -z /opt/csw/libexec/dovecot/auth || ../.././install-sh -c -d /opt/csw/libexec/dovecot/auth This || install part seems wrong, but it happens with me too. But the main problem is that why does test -z fail above? The auth binary should have been installed there already, so test -z should return success. Or is the auth file zero bytes long? Something's wrong with that..
Re: [Dovecot] v2.0.0 released
On Tue, 2010-08-17 at 17:32 +0100, Timo Sirainen wrote: test -z /opt/csw/libexec/dovecot/auth || ../.././install-sh -c -d /opt/csw/libexec/dovecot/auth This || install part seems wrong, but it happens with me too. But the main problem is that why does test -z fail above? The auth binary should have been installed there already, so test -z should return success. Or is the auth file zero bytes long? Something's wrong with that.. Uh. No, I remembered wrong. test -z tests if the string is empty. And of course the above string isn't empty. And looks like the mkdir is run with Linux, but it doesn't report a failure. Umm..
Re: [Dovecot] v2.0.0 released
On Tue, 2010-08-17 at 17:48 +0100, Timo Sirainen wrote: On Tue, 2010-08-17 at 17:32 +0100, Timo Sirainen wrote: test -z /opt/csw/libexec/dovecot/auth || ../.././install-sh -c -d /opt/csw/libexec/dovecot/auth This || install part seems wrong, but it happens with me too. But the main problem is that why does test -z fail above? The auth binary should have been installed there already, so test -z should return success. Or is the auth file zero bytes long? Something's wrong with that.. Uh. No, I remembered wrong. test -z tests if the string is empty. And of course the above string isn't empty. And looks like the mkdir is run with Linux, but it doesn't report a failure. Umm.. Oh, right. The above should be: test -z /opt/csw/lib/dovecot/auth || /bin/mkdir -p /opt/csw/lib/dovecot/auth Why is it libexec and not lib? What parameters did you give to configure? Looks as if you gave --libdir=/opt/csw/libexec
Re: [Dovecot] v2.0.0 released
On Tue, 2010-08-17 at 09:34 -0400, Dennis Clarke wrote: libtool: install: ../.././install-sh -c .libs/auth /opt/csw/libexec/dovecot/auth Which sure looks like the file auth being copied into place Yes, that's correct. and then right after we get a failure : libtool: install: ../.././install-sh -c .libs/checkpassword-reply /opt/csw/libexec/dovecot/checkpassword-reply This is also correct. test -z /opt/csw/libexec/dovecot/auth || ../.././install-sh -c -d /opt/csw/libexec/dovecot/auth This || install part seems wrong, but it happens with me too. But the main problem is that why does test -z fail above? The auth binary should have been installed there already, so test -z should return success. Or is the auth file zero bytes long? Something's wrong with that.. No it is a real valid Sparc binary : # file /opt/csw/libexec/dovecot/auth /opt/csw/libexec/dovecot/auth: ELF 32-bit MSB executable SPARC Version 1, dynamically linked, not stripped I'm going to experiment a bit here ... I have a theory but it will take hours to track down. Dennis
Re: [Dovecot] v2.0.0 released
On Tue, 2010-08-17 at 17:48 +0100, Timo Sirainen wrote: On Tue, 2010-08-17 at 17:32 +0100, Timo Sirainen wrote: test -z /opt/csw/libexec/dovecot/auth || ../.././install-sh -c -d /opt/csw/libexec/dovecot/auth This || install part seems wrong, but it happens with me too. But the main problem is that why does test -z fail above? The auth binary should have been installed there already, so test -z should return success. Or is the auth file zero bytes long? Something's wrong with that.. Uh. No, I remembered wrong. test -z tests if the string is empty. And of course the above string isn't empty. And looks like the mkdir is run with Linux, but it doesn't report a failure. Umm.. Oh, right. The above should be: test -z /opt/csw/lib/dovecot/auth || /bin/mkdir -p /opt/csw/lib/dovecot/auth Why is it libexec and not lib? What parameters did you give to configure? Looks as if you gave --libdir=/opt/csw/libexec This may help : [titan] more ../../sparc/dovecot-2.0.0-sparcv8-002/config.log This file contains any messages produced by compilers while running configure, to aid debugging if configure makes a mistake. It was created by Dovecot configure 2.0.0, which was generated by GNU Autoconf 2.65. Invocation command line was $ ./configure --build=sparc-sun-solaris2.8 --host=sparc-sun-solaris2.8 --prefi x=/opt/csw --sysconfdir=/etc/opt/csw/dovecot --localstatedir=/var/opt/csw/doveco t --enable-shared --enable-static --with-ioloop=poll --with-shadow --with-pam -- with-ldap=yes --with-sql=yes --with-mysql --with-sqlite --with-zlib --with-bzlib --with-ssl=openssl --with-storages=mbox,maildir --with-libiconv-prefix=/opt/csw --with-gssapi=yes --with-pgsql --with-libwrap --with-ssldir=/etc/opt/csw/ssl -- with-moduledir=/opt/csw/libexec/dovecot ## - ## ## Platform. ## ## - ## hostname = mimas uname -m = sun4u uname -r = 5.8 uname -s = SunOS uname -v = Generic_127721-03 /usr/bin/uname -p = sparc /bin/uname -X = System = SunOS Node = mimas Release = 5.8 KernelID = Generic_127721-03 Machine = sun4u BusType = unknown Serial = unknown Users = unknown OEM# = 0 Origin# = 1 NumCPU = 1 /bin/arch = sun4 /usr/bin/arch -k = sun4u /usr/convex/getsysinfo = unknown /usr/bin/hostinfo = unknown /bin/machine = unknown /usr/bin/oslevel = unknown /bin/universe = unknown PATH: /opt/csw/gcc4/bin PATH: /opt/csw/bin PATH: /usr/xpg4/bin PATH: /usr/ccs/bin PATH: /usr/bin PATH: /sbin PATH: /bin PATH: /usr/sbin PATH: /opt/schily/bin
Re: [Dovecot] v2.0.0 released
On Tue, 2010-08-17 at 13:15 -0400, Dennis Clarke wrote: [titan] more ../../sparc/dovecot-2.0.0-sparcv8-002/config.log This file contains any messages produced by compilers while running configure, to aid debugging if configure makes a mistake. .. --with-moduledir=/opt/csw/libexec/dovecot This is wrong. Modules don't belong under libexec.
Re: [Dovecot] v2.0.0 released
On Tue, 2010-08-17 at 13:15 -0400, Dennis Clarke wrote: [titan] more ../../sparc/dovecot-2.0.0-sparcv8-002/config.log This file contains any messages produced by compilers while running configure, to aid debugging if configure makes a mistake. .. --with-moduledir=/opt/csw/libexec/dovecot This is wrong. Modules don't belong under libexec. Where would you like them ?
Re: [Dovecot] v2.0.0 released
On Tue, 2010-08-17 at 13:19 -0400, Dennis Clarke wrote: On Tue, 2010-08-17 at 13:15 -0400, Dennis Clarke wrote: [titan] more ../../sparc/dovecot-2.0.0-sparcv8-002/config.log This file contains any messages produced by compilers while running configure, to aid debugging if configure makes a mistake. .. --with-moduledir=/opt/csw/libexec/dovecot This is wrong. Modules don't belong under libexec. Where would you like them ? Default location would be fine (= lib). Anything except libexec, since it creates a conflict.
Re: [Dovecot] v2.0.0 released
On Tue, 2010-08-17 at 13:19 -0400, Dennis Clarke wrote: On Tue, 2010-08-17 at 13:15 -0400, Dennis Clarke wrote: [titan] more ../../sparc/dovecot-2.0.0-sparcv8-002/config.log This file contains any messages produced by compilers while running configure, to aid debugging if configure makes a mistake. .. --with-moduledir=/opt/csw/libexec/dovecot This is wrong. Modules don't belong under libexec. Where would you like them ? Default location would be fine (= lib). Anything except libexec, since it creates a conflict. I'm doing a recompile and tossing --with-moduledir out :-)
[Dovecot] v2.0.0 released
http://dovecot.org/releases/2.0/dovecot-2.0.0.tar.gz http://dovecot.org/releases/2.0/dovecot-2.0.0.tar.gz.sig As promised last Friday, here's the v2.0.0 release finally. I'm cautiously optimistic that v2.0.1 won't (have to) be released for a few weeks, since there was quite a lot of testing and fixing going on in the RC stage. Remember to read http://wiki2.dovecot.org/Upgrading/2.0 before upgrading from v1.x. Although there is automatic config conversion, it can't handle everything, so reserve some extra time for upgrading. If you find an upgrade problem that isn't listed on the wiki page, please add it there or email Dovecot mailing list about it. Pigeonhole Sieve and ManageSieve support can now be installed without patching Dovecot. Unfortunately there isn't a Pigeonhole release yet for v2.0, but its Mercurial code tree should be quite stable. See http://wiki2.dovecot.org/Pigeonhole There are no changes since v2.0.rc6. The largest changes since v1.2 are: * Dovecot uses two system users for internal purposes now by default: dovenull and dovecot. You need to create the dovenull user or change default_login_user setting. * Global ACLs are now looked up using namespace prefixes. For example if you previously had INBOX. namespace prefix and a global ACL for INBOX.Sent, it's now looked up from INBOX.Sent file instead of Sent as before. * Maildir: File permissions are no longer based on dovecot-shared file, but the mailbox directory. + Redesigned master process. It's now more modular and there is less code running as root. + Configuration supports now per-local/remote ip/network settings. + dsync utility does a two-way mailbox synchronization. + LMTP server and proxying. + Added mdbox (multi-dbox) mail storage backend. + doveadm utility can be used to do all kinds of administration functions. Old dovecotpw and *view utilities now exist in its subcommands. + imap and pop3 processes can now handle multiple connections. + IMAP: COMPRESS=DEFLATE is supported by imap_zlib plugin + director service helps NFS installations to redirect users always to same server to avoid corruption
Re: [Dovecot] v2.0.0 released
On 16/08/2010 15:49, Timo Sirainen wrote: As promised last Friday, here's the v2.0.0 release finally. Brilliant work Timo! Bill
Re: [Dovecot] v2.0.0 released
On 8/16/10 10:49 AM, Timo Sirainen wrote: As promised last Friday, here's the v2.0.0 release finally. Congratulations, Timo! -Dave -- Dave McGuire Port Charlotte, FL
Re: [Dovecot] v2.0.0 released
On Mon, 2010-08-16 at 15:49 +0100, Timo Sirainen wrote: http://dovecot.org/releases/2.0/dovecot-2.0.0.tar.gz http://dovecot.org/releases/2.0/dovecot-2.0.0.tar.gz.sig Well, it didn't take long for someone to find the first bug: http://hg.dovecot.org/dovecot-2.0/rev/2156583b00e2 configure: v2.0.0 is no longer UNSTABLE development branch. --- a/configure.in Mon Aug 16 15:35:16 2010 +0100 +++ b/configure.in Mon Aug 16 16:07:01 2010 +0100 @@ -2739,6 +2739,3 @@ if test $not_sql_drivers != ; then echo :$not_sql_drivers fi - -echo -echo NOTE: This is the UNSTABLE development branch of Dovecot v2.0.
Re: [Dovecot] v2.0.0 released
On Mon, Aug 16, 2010 at 5:49 PM, Timo Sirainen t...@iki.fi wrote: http://dovecot.org/releases/2.0/dovecot-2.0.0.tar.gz http://dovecot.org/releases/2.0/dovecot-2.0.0.tar.gz.sig As promised last Friday, here's the v2.0.0 release finally. I'm cautiously optimistic that v2.0.1 won't (have to) be released for a few weeks, since there was quite a lot of testing and fixing going on in the RC stage. Remember to read http://wiki2.dovecot.org/Upgrading/2.0 before upgrading from v1.x. Although there is automatic config conversion, it can't handle everything, so reserve some extra time for upgrading. If you find an upgrade problem that isn't listed on the wiki page, please add it there or email Dovecot mailing list about it. Pigeonhole Sieve and ManageSieve support can now be installed without patching Dovecot. Unfortunately there isn't a Pigeonhole release yet for v2.0, but its Mercurial code tree should be quite stable. See http://wiki2.dovecot.org/Pigeonhole There are no changes since v2.0.rc6. The largest changes since v1.2 are: * Dovecot uses two system users for internal purposes now by default: dovenull and dovecot. You need to create the dovenull user or change default_login_user setting. * Global ACLs are now looked up using namespace prefixes. For example if you previously had INBOX. namespace prefix and a global ACL for INBOX.Sent, it's now looked up from INBOX.Sent file instead of Sent as before. * Maildir: File permissions are no longer based on dovecot-shared file, but the mailbox directory. + Redesigned master process. It's now more modular and there is less code running as root. + Configuration supports now per-local/remote ip/network settings. + dsync utility does a two-way mailbox synchronization. + LMTP server and proxying. + Added mdbox (multi-dbox) mail storage backend. + doveadm utility can be used to do all kinds of administration functions. Old dovecotpw and *view utilities now exist in its subcommands. + imap and pop3 processes can now handle multiple connections. + IMAP: COMPRESS=DEFLATE is supported by imap_zlib plugin + director service helps NFS installations to redirect users always to same server to avoid corruption It is yet another major milestone for Dovecot! Congratulations Timo. -- Best regards, Odhiambo WASHINGTON, Nairobi,KE +254733744121/+254722743223 _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ If you have nothing good to say about someone, just shut up!. -- Lucky Dube
Re: [Dovecot] v2.0.0 released
Congratulations Timo!:) SUSE packages are already building and can be found at [1] in a few minutes. though the package doesnt try to migrate the config yet. so users have to do that on their own. :) darix [1] http://download.opensuse.org/repositories/server:/mail/ dovecot20 dovecot20-backend-mysql dovecot20-backend-pgsql dovecot20-backend-sqlite dovecot20-fts-solr dovecot20-devel -- openSUSE - SUSE Linux is my linux openSUSE is good for you www.opensuse.org
Re: [Dovecot] v2.0.0 released
SUSE packages are already building and can be found at [1] in a few minutes. forgot to mention: the package ships with latest pigeonhole aswell. darix -- openSUSE - SUSE Linux is my linux openSUSE is good for you www.opensuse.org
Re: [Dovecot] v2.0.0 released
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Timo Sirainen said the following on 16/08/10 16:49: As promised last Friday, here's the v2.0.0 release finally. I'm cautiously optimistic that v2.0.1 won't (have to) be released for a few weeks, since there was quite a lot of testing and fixing going on in the RC stage. Congratulations Timo and thank you!!! Ciao, luigi - -- / +--[Luigi Rosa]-- \ Biggest Black Hole ever Found in Nearby Galaxy. EVERYBODY PAN..IC --fark.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkxpX2YACgkQ3kWu7Tfl6ZSHBACfYqBFlpHe0Cc4pRMx+b2OZZL9 P0QAoIwCuMkwS6w4SQpusyWwJWUQY+SN =k0GJ -END PGP SIGNATURE-
Re: [Dovecot] v2.0.0 released
http://dovecot.org/releases/2.0/dovecot-2.0.0.tar.gz http://dovecot.org/releases/2.0/dovecot-2.0.0.tar.gz.sig As promised last Friday, here's the v2.0.0 release finally. I'm cautiously optimistic that v2.0.1 won't (have to) be released for a few weeks, since there was quite a lot of testing and fixing going on in the RC stage. cool .. .however .. should I see this message at the end of the configure stage : . . . passdbs : static passwd passwd-file shadow pam checkpassword ldap sql : -bsdauth -sia -vpopmail userdbs : static prefetch passwd passwd-file checkpassword ldap sql : -vpopmail -nss SQL drivers : mysql sqlite : -pgsql NOTE: This is the UNSTABLE development branch of Dovecot v2.0. ^ That won't go well with the Solaris crowd. Just FYI. -- Dennis Clarke dcla...@opensolaris.ca - Email related to the open source Solaris dcla...@blastwave.org - Email related to open source for Solaris
Re: [Dovecot] v2.0.0 released
On 08/16/2010 06:46 PM Dennis Clarke wrote: … NOTE: This is the UNSTABLE development branch of Dovecot v2.0. ^ See: http://dovecot.org/list/dovecot/2010-August/051736.html Regards, Pascal -- The trapper recommends today: cafefeed.1022...@localdomain.org
Re: [Dovecot] v2.0.0 released
On 08/16/2010 06:46 PM Dennis Clarke wrote: ⦠NOTE: This is the UNSTABLE development branch of Dovecot v2.0. ^ See: http://dovecot.org/list/dovecot/2010-August/051736.html wow ... I was hoping I was the first :-\ -- Dennis Clarke dcla...@opensolaris.ca - Email related to the open source Solaris dcla...@blastwave.org - Email related to open source for Solaris
Re: [Dovecot] v2.0.0 released
Well , configure looked good and the summary seemed fine :
Install prefix . : /opt/csw
File offsets ... : 64bit
I/O polling : poll
I/O notifys : none
SSL : yes (OpenSSL)
GSSAPI . : yes
passdbs : static passwd passwd-file shadow pam checkpassword ldap
sql
: -bsdauth -sia -vpopmail
userdbs : static prefetch passwd passwd-file checkpassword ldap sql
: -vpopmail -nss
SQL drivers : pgsql mysql sqlite
Everything was going swimmingly and then poof :
libtool: compile: /opt/studio/SOS11/SUNWspro/bin/cc -DHAVE_CONFIG_H -I.
-I../.. -I../../src/lib -I../../src/lib-test -I../../src/lib-charset
-I../../src/lib-mail
-I/opt/csw/include:/opt/csw/mysql51/include/mysql:/opt/csw/postgresql83/include
-I/opt/csw/include -xstrconst -xildoff -xarch=v8 -xnolibmil -Xa
-xcode=pic32 -xregs=no%appl -xlibmieee -g -xs -I/opt/csw/include
-I/opt/csw/mysql51/include/mysql -I/opt/csw/postgresql83/include
-D_TS_ERRNO -DSOLARIS2=8 -D_LARGEFILE64_SOURCE -I/opt/csw/include -c
imap-id.c -KPIC -DPIC -o .libs/imap-id.o
libtool: compile: /opt/studio/SOS11/SUNWspro/bin/cc -DHAVE_CONFIG_H -I.
-I../.. -I../../src/lib -I../../src/lib-test -I../../src/lib-charset
-I../../src/lib-mail
-I/opt/csw/include:/opt/csw/mysql51/include/mysql:/opt/csw/postgresql83/include
-I/opt/csw/include -xstrconst -xildoff -xarch=v8 -xnolibmil -Xa
-xcode=pic32 -xregs=no%appl -xlibmieee -g -xs -I/opt/csw/include
-I/opt/csw/mysql51/include/mysql -I/opt/csw/postgresql83/include
-D_TS_ERRNO -DSOLARIS2=8 -D_LARGEFILE64_SOURCE -I/opt/csw/include -c
imap-id.c -o imap-id.o /dev/null 21
source='imap-match.c' object='imap-match.lo' libtool=yes \
DEPDIR=.deps depmode=none /opt/csw/bin/bash ../../depcomp \
/opt/csw/bin/bash ../../libtool --tag=CC --mode=compile
/opt/studio/SOS11/SUNWspro/bin/cc -DHAVE_CONFIG_H -I. -I../..
-I../../src/lib -I../../src/lib-test -I../../src/lib-charset
-I../../src/lib-mail
-I/opt/csw/include:/opt/csw/mysql51/include/mysql:/opt/csw/postgresql83/include
-I/opt/csw/include -xstrconst -xildoff -xarch=v8 -xnolibmil -Xa
-xcode=pic32 -xregs=no%appl -xlibmieee -g -xs -I/opt/csw/include
-I/opt/csw/mysql51/include/mysql -I/opt/csw/postgresql83/include
-D_TS_ERRNO -DSOLARIS2=8 -D_LARGEFILE64_SOURCE -I/opt/csw/include-c -o
imap-match.lo imap-match.c
libtool: compile: /opt/studio/SOS11/SUNWspro/bin/cc -DHAVE_CONFIG_H -I.
-I../.. -I../../src/lib -I../../src/lib-test -I../../src/lib-charset
-I../../src/lib-mail
-I/opt/csw/include:/opt/csw/mysql51/include/mysql:/opt/csw/postgresql83/include
-I/opt/csw/include -xstrconst -xildoff -xarch=v8 -xnolibmil -Xa
-xcode=pic32 -xregs=no%appl -xlibmieee -g -xs -I/opt/csw/include
-I/opt/csw/mysql51/include/mysql -I/opt/csw/postgresql83/include
-D_TS_ERRNO -DSOLARIS2=8 -D_LARGEFILE64_SOURCE -I/opt/csw/include -c
imap-match.c -KPIC -DPIC -o .libs/imap-match.o
imap-match.c, line 199: identifier redeclared: imap_match_dup
current : function(pointer to struct pool {pointer to const struct
pool_vfuncs {..} v, unsigned int alloconly_pool :1, unsigned int
datastack_pool :1}, pointer to const struct imap_match_glob
{pointer to struct pool {..} pool, pointer to struct
imap_match_pattern {..} patterns, char sep, array[-1] of char
patterns_data}) returning pointer to struct imap_match_glob
{pointer to struct pool {..} pool, pointer to struct
imap_match_pattern {..} patterns, char sep, array[-1] of char
patterns_data}
previous: function(pointer to struct pool {pointer to const struct
pool_vfuncs {..} v, unsigned int alloconly_pool :1, unsigned int
datastack_pool :1}, pointer to const struct imap_match_glob
{pointer to struct pool {..} pool, pointer to struct
imap_match_pattern {..} patterns, char sep, array[-1] of char
patterns_data}) returning pointer to struct imap_match_glob
{pointer to struct pool {..} pool, pointer to struct
imap_match_pattern {..} patterns, char sep, array[-1] of char
patterns_data} : imap-match.h, line 33
imap-match.c, line 214: identifier redeclared: imap_match_globs_equal
current : function(pointer to const struct imap_match_glob
{pointer to struct pool {..} pool, pointer to struct
imap_match_pattern {..} patterns, char sep, array[-1] of char
patterns_data}, pointer to const struct imap_match_glob {pointer
to struct pool {..} pool, pointer to struct imap_match_pattern
{..} patterns, char sep, array[-1] of char patterns_data})
returning _Bool
previous: function(pointer to const struct imap_match_glob
{pointer to struct pool {..} pool, pointer to struct
imap_match_pattern {..} patterns, char sep, array[-1] of char
patterns_data}, pointer to const struct imap_match_glob {pointer
to struct pool {..} pool, pointer to struct imap_match_pattern
{..} patterns, char sep, array[-1] of char patterns_data})
returning _Bool : imap-match.h, line 36
cc: acomp failed for imap-match.c
gmake[3]: *** [imap-match.lo] Error 1
gmake[3]: Leaving directory
Re: [Dovecot] v2.0.0 released
On 16.8.2010, at 23.25, Dennis Clarke wrote: imap-match.c, line 199: identifier redeclared: imap_match_dup I think someone reported this problem earlier .. but I'm not sure. Anyway I've no idea why it would complain about this. So that stops me while I figure out what the issue is with imap-match.h and/or imap-match.c in the Solaris world while using Sun Studio 11. I heard it compiles ok with Sun Studio 12.1.
Re: [Dovecot] v2.0.0 released
On 8/16/10 6:25 PM, Dennis Clarke wrote:
pool_vfuncs {..} v, unsigned int alloconly_pool :1, unsigned int
datastack_pool :1}, pointer to const struct imap_match_glob
{pointer to struct pool {..} pool, pointer to struct
imap_match_pattern {..} patterns, char sep, array[-1] of char
patterns_data}) returning pointer to struct imap_match_glob
{pointer to struct pool {..} pool, pointer to struct
imap_match_pattern {..} patterns, char sep, array[-1] of char
patterns_data}
previous: function(pointer to struct pool {pointer to const struct
pool_vfuncs {..} v, unsigned int alloconly_pool :1, unsigned int
datastack_pool :1}, pointer to const struct imap_match_glob
{pointer to struct pool {..} pool, pointer to struct
imap_match_pattern {..} patterns, char sep, array[-1] of char
patterns_data}) returning pointer to struct imap_match_glob
{pointer to struct pool {..} pool, pointer to struct
imap_match_pattern {..} patterns, char sep, array[-1] of char
patterns_data} : imap-match.h, line 33
imap-match.c, line 214: identifier redeclared: imap_match_globs_equal
current : function(pointer to const struct imap_match_glob
{pointer to struct pool {..} pool, pointer to struct
imap_match_pattern {..} patterns, char sep, array[-1] of char
patterns_data}, pointer to const struct imap_match_glob {pointer
to struct pool {..} pool, pointer to struct imap_match_pattern
{..} patterns, char sep, array[-1] of char patterns_data})
returning _Bool
previous: function(pointer to const struct imap_match_glob
{pointer to struct pool {..} pool, pointer to struct
imap_match_pattern {..} patterns, char sep, array[-1] of char
patterns_data}, pointer to const struct imap_match_glob {pointer
to struct pool {..} pool, pointer to struct imap_match_pattern
{..} patterns, char sep, array[-1] of char patterns_data})
returning _Bool : imap-match.h, line 36
cc: acomp failed for imap-match.c
gmake[3]: *** [imap-match.lo] Error 1
gmake[3]: Leaving directory
`/export/medusa/dclarke/build/dovecot/sparc/dovecot-2.0.0-sparcv8-001/src/lib-imap'
gmake[2]: *** [all-recursive] Error 1
gmake[2]: Leaving directory
`/export/medusa/dclarke/build/dovecot/sparc/dovecot-2.0.0-sparcv8-001/src'
gmake[1]: *** [all-recursive] Error 1
gmake[1]: Leaving directory
`/export/medusa/dclarke/build/dovecot/sparc/dovecot-2.0.0-sparcv8-001'
gmake: *** [all] Error 2
[mimas]
So that stops me while I figure out what the issue is with imap-match.h
and/or imap-match.c in the Solaris world while using Sun Studio 11.
Works fine here with the 12.1 compiler. Solaris 10 on UltraSPARC,
current patches, on both the OS and the compilers. My CFLAGS:
-fast -xtarget=ultra3 -m32 -xarch=sparcvis2
-Dave
--
Dave McGuire
Port Charlotte, FL
Re: [Dovecot] v2.0.0 released
On 16.8.2010, at 23.25, Dennis Clarke wrote: imap-match.c, line 199: identifier redeclared: imap_match_dup I think someone reported this problem earlier .. but I'm not sure. Anyway I've no idea why it would complain about this. So that stops me while I figure out what the issue is with imap-match.h and/or imap-match.c in the Solaris world while using Sun Studio 11. I heard it compiles ok with Sun Studio 12.1. I will try GCC and let you know what I see : [mimas] gcc --version gcc (Blastwave.org Inc. Mon Aug 9 07:10:45 GMT 2010) 4.5.1 Copyright (C) 2010 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. No surprise that GCC works fine : [mimas] ls -lap ./src/master/.libs/dovecot -rwxr-xr-x 1 dclarke csw86388 Aug 17 00:09 ./src/master/.libs/dovecot [mimas] file ./src/master/.libs/dovecot ./src/master/.libs/dovecot: ELF 32-bit MSB executable SPARC Version 1, dynamically linked, not stripped [mimas] elfdump -d ./src/master/.libs/dovecot Dynamic Section: .dynamic index tag value [0] NEEDED 0xe21 libdovecot.so.0 [1] NEEDED 0xe31 libintl.so.8 [2] NEEDED 0xe3e libdl.so.1 [3] NEEDED 0xe49 libnsl.so.1 [4] NEEDED 0xdf6 libsocket.so.1 [5] NEEDED 0xe55 libiconv.so.2 [6] NEEDED 0xe0e libc.so.1 [7] NEEDED 0xe63 librt.so.1 [8] INIT 0x1b71c [9] FINI 0x1b738 etc etc ... I did see a few odd messages fly by like this : *** Warning: Linking the shared library lib30_imap_zlib_plugin.la against the loadable module *** lib20_zlib_plugin.so is not portable! Not too sure what is up with that but I'll look into it. -- Dennis Clarke dcla...@opensolaris.ca - Email related to the open source Solaris dcla...@blastwave.org - Email related to open source for Solaris
Re: [Dovecot] v2.0.0 released
On 17.8.2010, at 1.28, Dennis Clarke wrote: *** Warning: Linking the shared library lib30_imap_zlib_plugin.la against the loadable module *** lib20_zlib_plugin.so is not portable! Not too sure what is up with that but I'll look into it. That's normal. It doesn't need to be portable.
Re: [Dovecot] v2.0.0 released
So that stops me while I figure out what the issue is with imap-match.h and/or imap-match.c in the Solaris world while using Sun Studio 11. Works fine here with the 12.1 compiler. Solaris 10 on UltraSPARC, current patches, on both the OS and the compilers. My CFLAGS: -fast -xtarget=ultra3 -m32 -xarch=sparcvis2 The is ye ol'production Solaris 8 and thus Sun Studio 11 is needed. Problem solved simply by using GCC 4.5.1 from Blastwave ( of course ). Question for you: why would you use -m32 with an -xarch=sparcvis2 ? Why not go for greatest possible portability and range of processors with something like this : CFLAGS=-m32 -Qy -Xa -xbuiltin=%none -xnolibmil -xnolibmopt -xcode=pic32 -xildoff -xregs=no%appl -xs -xstrconst -D_TS_ERRNO If you feel like some optimization then chuck in -xO3 and -xdepend however I'd test the resultant bins from a basic compile first. Just my 0.02 -- Dennis Clarke dcla...@opensolaris.ca - Email related to the open source Solaris dcla...@blastwave.org - Email related to open source for Solaris
Re: [Dovecot] v2.0.0 released
On 8/16/10 8:38 PM, Dennis Clarke wrote: Works fine here with the 12.1 compiler. Solaris 10 on UltraSPARC, current patches, on both the OS and the compilers. My CFLAGS: -fast -xtarget=ultra3 -m32 -xarch=sparcvis2 The is ye ol'production Solaris 8 and thus Sun Studio 11 is needed. Oh. Eeeew. :) Problem solved simply by using GCC 4.5.1 from Blastwave ( of course ). I wonder how GCCFSS would do. Will it even run under Solaris 8? Question for you: why would you use -m32 with an -xarch=sparcvis2 ? Why not go for greatest possible portability and range of processors with something like this : CFLAGS=-m32 -Qy -Xa -xbuiltin=%none -xnolibmil -xnolibmopt -xcode=pic32 -xildoff -xregs=no%appl -xs -xstrconst -D_TS_ERRNO Because I don't intend to run it on a range of processors. =) If you feel like some optimization then chuck in -xO3 and -xdepend however I'd test the resultant bins from a basic compile first. Just my 0.02 Fair enough, and I appreciate your advice. My goal in this case is to generate the fastest binaries possible on the machine it's being built on, which is identical to the machine it's going to be run on. There's zero need for portable binaries in this particular installation. -Dave -- Dave McGuire Port Charlotte, FL
Re: [Dovecot] v2.0.0 released
On 17.8.2010, at 1.28, Dennis Clarke wrote: *** Warning: Linking the shared library lib30_imap_zlib_plugin.la against the loadable module *** lib20_zlib_plugin.so is not portable! Not too sure what is up with that but I'll look into it. That's normal. It doesn't need to be portable. In that case ... awesome :-) I'll let you know when I get packages into testing QC and then for release. However I am going to rename the package to dovecot2 in order to separate it from dovecot 1.x installs. My idea there is to allow the user to continue with the dovecot 1.x line in the event of patch updates and further releases from that tree ( like dovecot 1.2.13 ) while also maintaining the ver 2.x family. However I don't think I'll support multiple instances of dovecot ( regardless of version ) in the same Solaris zone. If the user wants that then they can do all the uid/pid hackery themselves. -- Dennis Clarke dcla...@opensolaris.ca - Email related to the open source Solaris dcla...@blastwave.org - Email related to open source for Solaris
Re: [Dovecot] v2.0.0 released
On 8/16/10 8:38 PM, Dennis Clarke wrote: Works fine here with the 12.1 compiler. Solaris 10 on UltraSPARC, current patches, on both the OS and the compilers. My CFLAGS: -fast -xtarget=ultra3 -m32 -xarch=sparcvis2 The is ye ol'production Solaris 8 and thus Sun Studio 11 is needed. Oh. Eeeew. :) Hey, there are banks and telco places all over that are running it and they *refuse* to upgrade. I know of government sites that are still on old E450's because they have not died yet. No kidding. Some of that old Sun gear just WILL NOT bloody die. The way to justify the capital expenditure on a new Sun Sparc server is to spill a coffee on/in it. 8-P Problem solved simply by using GCC 4.5.1 from Blastwave ( of course ). I wonder how GCCFSS would do. Will it even run under Solaris 8? Why not ? It is a rock solid kernel and you can build it and see :-) Question for you: why would you use -m32 with an -xarch=sparcvis2 ? Why not go for greatest possible portability and range of processors with something like this : CFLAGS=-m32 -Qy -Xa -xbuiltin=%none -xnolibmil -xnolibmopt -xcode=pic32 -xildoff -xregs=no%appl -xs -xstrconst -D_TS_ERRNO Because I don't intend to run it on a range of processors. =) ah ... I am in a different world. If you feel like some optimization then chuck in -xO3 and -xdepend however I'd test the resultant bins from a basic compile first. Just my 0.02 Fair enough, and I appreciate your advice. My goal in this case is to generate the fastest binaries possible on the machine it's being built on, which is identical to the machine it's going to be run on. There's zero need for portable binaries in this particular installation. In that case run fpversion : fpversion A SPARC-based CPU is available. Kernel says CPU's clock rate is 900.0 MHz. Kernel says main memory's clock rate is 150.0 MHz. Sun-4 floating-point controller version 0 found. An UltraSPARC chip is available. Use -xtarget=ultra3cu -xcache=64/32/4:8192/512/2 code-generation option. See those compiler options ? Use them. Also put in -xO3 and -xdepend and then the compile will take a lot longer but you will be happy you waited. Sun Studio compilers can really rock if you know how to push them. -- Dennis Clarke dcla...@opensolaris.ca - Email related to the open source Solaris dcla...@blastwave.org - Email related to open source for Solaris
Re: [Dovecot] v2.0.0 released
I wonder how GCCFSS would do. Will it even run under Solaris 8? # which gcc /opt/csw/gcc4/bin/gcc # gcc --version gcc (Blastwave.org Inc. Mon Aug 9 07:10:45 GMT 2010) 4.5.1 Copyright (C) 2010 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. # uname -a SunOS mimas 5.8 Generic_127721-03 sun4u sparc SUNW,UltraAX-i2 # psrinfo -v Status of virtual processor 0 as of: 08/17/10 00:58:04 on-line since 07/06/10 12:03:37. The sparcv9 processor operates at 500 MHz, and has a sparcv9 floating point processor. Is that baseline Sparc enough for you ? ;-) -- Dennis Clarke dcla...@opensolaris.ca - Email related to the open source Solaris dcla...@blastwave.org - Email related to open source for Solaris
