Hi list, Here it is: I have compiled with no problem courier-imap-4.0.4 on this arch (x86_64). Now I want to update my install with 4.0.6. I want to do this because the server is not yet in a production state, so if a major flaw affects courier-imap in the future, I could react more quickly. And indeed I'm encountering problems with the make process (Since I initialy build courier-imap from sources and that I dont want FAM, I'm not using the rpmbuild process). I've stricly followed the INSTALL's instructions.
I believe the problem comes from the mixed libraries living on the system (x86_64 and, for compatibility purpose, i386) and I didn't find a workaround on this. I'm near to switch to dovecot if it can handle quite large amount of users (500-1000 accounts). That would be bad because I think courier-imap is well doing its job. By the way, someone tolds me that courier-imap and RHEL4 (and clones) is a bad idea, someone can confirm? So:
[user@host courier-imap-4.0.6]$ ./configure --with-redhat ... // process goes ok, no warning no errors configure: creating ./config.status config.status: creating Makefile config.status: creating imapd.dist config.status: creating imapd-ssl.dist config.status: creating pop3d.dist config.status: creating pop3d-ssl.dist config.status: creating testsuitefix.pl config.status: creating mkimapdcert config.status: creating mkpop3dcert config.status: creating imapd.cnf config.status: creating pop3d.cnf config.status: creating config.h config.status: executing depfiles commands
[user@host courier-imap-4.0.6]$ make ... // I'm just pasting the first errors, the others seems to come from the first ones anyway: In file included from /usr/lib/gcc/x86_64-redhat-linux/3.4.4/../../../../include/c++/3.4.4/bits/stl_tree.h:66, from /usr/lib/gcc/x86_64-redhat-linux/3.4.4/../../../../include/c++/3.4.4/set:66, from maildirkeywords.h:435, from maildirkeywords4.cpp:9: /usr/lib/gcc/x86_64-redhat-linux/3.4.4/../../../../include/c++/3.4.4/bits/stl_algobase.h:64:28: bits/c++config.h: No such file or directory In file included from /usr/lib/gcc/x86_64-redhat-linux/3.4.4/../../../../include/c++/3.4.4/bits/stl_algobase.h:70, from /usr/lib/gcc/x86_64-redhat-linux/3.4.4/../../../../include/c++/3.4.4/bits/stl_tree.h:66, from /usr/lib/gcc/x86_64-redhat-linux/3.4.4/../../../../include/c++/3.4.4/set:66, from maildirkeywords.h:435, from maildirkeywords4.cpp:9: /usr/lib/gcc/x86_64-redhat-linux/3.4.4/../../../../include/c++/3.4.4/iosfwd:46:29: bits/c++locale.h: No such file or directory /usr/lib/gcc/x86_64-redhat-linux/3.4.4/../../../../include/c++/3.4.4/iosfwd:47:25: bits/c++io.h: No such file or directory In file included from /usr/lib/gcc/x86_64-redhat-linux/3.4.4/../../../../include/c++/3.4.4/bits/stl_tree.h:67, from /usr/lib/gcc/x86_64-redhat-linux/3.4.4/../../../../include/c++/3.4.4/set:66, from maildirkeywords.h:435, from maildirkeywords4.cpp:9: /usr/lib/gcc/x86_64-redhat-linux/3.4.4/../../../../include/c++/3.4.4/bits/allocator.h:52:31: bits/c++allocator.h: No such file or directory In file included from /usr/lib/gcc/x86_64-redhat-linux/3.4.4/../../../../include/c++/3.4.4/bits/stl_tree.h:67, from /usr/lib/gcc/x86_64-redhat-linux/3.4.4/../../../../include/c++/3.4.4/set:66, from maildirkeywords.h:435, from maildirkeywords4.cpp:9: /usr/lib/gcc/x86_64-redhat-linux/3.4.4/../../../../include/c++/3.4.4/bits/allocator.h:80: error: expected template-name before '<' token /usr/lib/gcc/x86_64-redhat-linux/3.4.4/../../../../include/c++/3.4.4/bits/allocator.h:80: error: expected `{' before '<' token /usr/lib/gcc/x86_64-redhat-linux/3.4.4/../../../../include/c++/3.4.4/bits/allocator.h:80: error: expected unqualified-id before '<' token /usr/lib/gcc/x86_64-redhat-linux/3.4.4/../../../../include/c++/3.4.4/bits/allocator.h:80: error: expected `;' before '<' token In file included from /usr/lib/gcc/x86_64-redhat-linux/3.4.4/../../../../include/c++/3.4.4/set:67, from maildirkeywords.h:435, from maildirkeywords4.cpp:9: ...
I think the problem comes from a missing flag or something like this due to the mixed arch. Can somebody help?
Best regards, kfx.
On 12/14/05, kadafax kadafax@gmail.com wrote:
Hi list, Here it is: I have compiled with no problem courier-imap-4.0.4 on this arch (x86_64). Now I want to update my install with 4.0.6. I want to do this because the server is not yet in a production state, so if a major flaw affects courier-imap in the future, I could react more quickly. And indeed I'm encountering problems with the make process (Since I initialy build courier-imap from sources and that I dont want FAM, I'm not using the rpmbuild process). I've stricly followed the INSTALL's instructions.
I believe the problem comes from the mixed libraries living on the system (x86_64 and, for compatibility purpose, i386) and I didn't find a workaround on this. I'm near to switch to dovecot if it can handle quite large amount of users (500-1000 accounts). That would be bad because I think courier-imap is well doing its job. By the way, someone tolds me that courier-imap and RHEL4 (and clones) is a bad idea, someone can confirm? So:
[user@host courier-imap-4.0.6]$ ./configure --with-redhat ... // process goes ok, no warning no errors configure: creating ./config.status config.status: creating Makefile config.status: creating imapd.dist config.status: creating imapd-ssl.dist config.status: creating pop3d.dist config.status: creating pop3d-ssl.dist config.status: creating testsuitefix.pl config.status: creating mkimapdcert config.status: creating mkpop3dcert config.status: creating imapd.cnf config.status: creating pop3d.cnf config.status: creating config.h config.status: executing depfiles commands
[user@host courier-imap-4.0.6]$ make ... // I'm just pasting the first errors, the others seems to come from the first ones anyway: In file included from /usr/lib/gcc/x86_64-redhat-linux/3.4.4/../../../../include/c++/3.4.4/bits/stl_tree.h:66, from /usr/lib/gcc/x86_64-redhat-linux/3.4.4/../../../../include/c++/3.4.4/set:66, from maildirkeywords.h:435, from maildirkeywords4.cpp:9: /usr/lib/gcc/x86_64-redhat-linux/3.4.4/../../../../include/c++/3.4.4/bits/stl_algobase.h:64:28: bits/c++config.h: No such file or directory In file included from /usr/lib/gcc/x86_64-redhat-linux/3.4.4/../../../../include/c++/3.4.4/bits/stl_algobase.h:70, from /usr/lib/gcc/x86_64-redhat-linux/3.4.4/../../../../include/c++/3.4.4/bits/stl_tree.h:66, from /usr/lib/gcc/x86_64-redhat-linux/3.4.4/../../../../include/c++/3.4.4/set:66, from maildirkeywords.h:435, from maildirkeywords4.cpp:9: /usr/lib/gcc/x86_64-redhat-linux/3.4.4/../../../../include/c++/3.4.4/iosfwd:46:29: bits/c++locale.h: No such file or directory /usr/lib/gcc/x86_64-redhat-linux/3.4.4/../../../../include/c++/3.4.4/iosfwd:47:25: bits/c++io.h: No such file or directory In file included from /usr/lib/gcc/x86_64-redhat-linux/3.4.4/../../../../include/c++/3.4.4/bits/stl_tree.h:67, from /usr/lib/gcc/x86_64-redhat-linux/3.4.4/../../../../include/c++/3.4.4/set:66, from maildirkeywords.h:435, from maildirkeywords4.cpp:9: /usr/lib/gcc/x86_64-redhat-linux/3.4.4/../../../../include/c++/3.4.4/bits/allocator.h:52:31: bits/c++allocator.h: No such file or directory In file included from /usr/lib/gcc/x86_64-redhat-linux/3.4.4/../../../../include/c++/3.4.4/bits/stl_tree.h:67, from /usr/lib/gcc/x86_64-redhat-linux/3.4.4/../../../../include/c++/3.4.4/set:66, from maildirkeywords.h:435, from maildirkeywords4.cpp:9: /usr/lib/gcc/x86_64-redhat-linux/3.4.4/../../../../include/c++/3.4.4/bits/allocator.h:80: error: expected template-name before '<' token /usr/lib/gcc/x86_64-redhat-linux/3.4.4/../../../../include/c++/3.4.4/bits/allocator.h:80: error: expected `{' before '<' token /usr/lib/gcc/x86_64-redhat-linux/3.4.4/../../../../include/c++/3.4.4/bits/allocator.h:80: error: expected unqualified-id before '<' token /usr/lib/gcc/x86_64-redhat-linux/3.4.4/../../../../include/c++/3.4.4/bits/allocator.h:80: error: expected `;' before '<' token In file included from /usr/lib/gcc/x86_64-redhat-linux/3.4.4/../../../../include/c++/3.4.4/set:67, from maildirkeywords.h:435, from maildirkeywords4.cpp:9: ...
Courier comes with a spec file for producing an rpm. You should consider using this for building instead, as it will usually help solve dependency/build issues or explain them in a slightly better way. rpmbuild -tb courier-foo.tar.bz2
-- Jim Perrin System Architect - UIT Ft Gordon & US Army Signal Center
On Wed, 2005-12-14 at 08:27 -0500, Jim Perrin wrote:
On 12/14/05, kadafax kadafax@gmail.com wrote:
Hi list, Here it is: I have compiled with no problem courier-imap-4.0.4 on this arch (x86_64). Now I want to update my install with 4.0.6. I want to do this because the server is not yet in a production state, so if a major flaw affects courier-imap in the future, I could react more quickly. And indeed I'm encountering problems with the make process (Since I initialy build courier-imap from sources and that I dont want FAM, I'm not using the rpmbuild process). I've stricly followed the INSTALL's instructions.
I believe the problem comes from the mixed libraries living on the system (x86_64 and, for compatibility purpose, i386) and I didn't find a workaround on this. I'm near to switch to dovecot if it can handle quite large amount of users (500-1000 accounts). That would be bad because I think courier-imap is well doing its job. By the way, someone tolds me that courier-imap and RHEL4 (and clones) is a bad idea, someone can confirm? So:
[user@host courier-imap-4.0.6]$ ./configure --with-redhat ... // process goes ok, no warning no errors configure: creating ./config.status config.status: creating Makefile config.status: creating imapd.dist config.status: creating imapd-ssl.dist config.status: creating pop3d.dist config.status: creating pop3d-ssl.dist config.status: creating testsuitefix.pl config.status: creating mkimapdcert config.status: creating mkpop3dcert config.status: creating imapd.cnf config.status: creating pop3d.cnf config.status: creating config.h config.status: executing depfiles commands
[user@host courier-imap-4.0.6]$ make ... // I'm just pasting the first errors, the others seems to come from the first ones anyway: In file included from /usr/lib/gcc/x86_64-redhat-linux/3.4.4/../../../../include/c++/3.4.4/bits/stl_tree.h:66, from /usr/lib/gcc/x86_64-redhat-linux/3.4.4/../../../../include/c++/3.4.4/set:66, from maildirkeywords.h:435, from maildirkeywords4.cpp:9: /usr/lib/gcc/x86_64-redhat-linux/3.4.4/../../../../include/c++/3.4.4/bits/stl_algobase.h:64:28: bits/c++config.h: No such file or directory In file included from /usr/lib/gcc/x86_64-redhat-linux/3.4.4/../../../../include/c++/3.4.4/bits/stl_algobase.h:70, from /usr/lib/gcc/x86_64-redhat-linux/3.4.4/../../../../include/c++/3.4.4/bits/stl_tree.h:66, from /usr/lib/gcc/x86_64-redhat-linux/3.4.4/../../../../include/c++/3.4.4/set:66, from maildirkeywords.h:435, from maildirkeywords4.cpp:9: /usr/lib/gcc/x86_64-redhat-linux/3.4.4/../../../../include/c++/3.4.4/iosfwd:46:29: bits/c++locale.h: No such file or directory /usr/lib/gcc/x86_64-redhat-linux/3.4.4/../../../../include/c++/3.4.4/iosfwd:47:25: bits/c++io.h: No such file or directory In file included from /usr/lib/gcc/x86_64-redhat-linux/3.4.4/../../../../include/c++/3.4.4/bits/stl_tree.h:67, from /usr/lib/gcc/x86_64-redhat-linux/3.4.4/../../../../include/c++/3.4.4/set:66, from maildirkeywords.h:435, from maildirkeywords4.cpp:9: /usr/lib/gcc/x86_64-redhat-linux/3.4.4/../../../../include/c++/3.4.4/bits/allocator.h:52:31: bits/c++allocator.h: No such file or directory In file included from /usr/lib/gcc/x86_64-redhat-linux/3.4.4/../../../../include/c++/3.4.4/bits/stl_tree.h:67, from /usr/lib/gcc/x86_64-redhat-linux/3.4.4/../../../../include/c++/3.4.4/set:66, from maildirkeywords.h:435, from maildirkeywords4.cpp:9: /usr/lib/gcc/x86_64-redhat-linux/3.4.4/../../../../include/c++/3.4.4/bits/allocator.h:80: error: expected template-name before '<' token /usr/lib/gcc/x86_64-redhat-linux/3.4.4/../../../../include/c++/3.4.4/bits/allocator.h:80: error: expected `{' before '<' token /usr/lib/gcc/x86_64-redhat-linux/3.4.4/../../../../include/c++/3.4.4/bits/allocator.h:80: error: expected unqualified-id before '<' token /usr/lib/gcc/x86_64-redhat-linux/3.4.4/../../../../include/c++/3.4.4/bits/allocator.h:80: error: expected `;' before '<' token In file included from /usr/lib/gcc/x86_64-redhat-linux/3.4.4/../../../../include/c++/3.4.4/set:67, from maildirkeywords.h:435, from maildirkeywords4.cpp:9: ...
Courier comes with a spec file for producing an rpm. You should consider using this for building instead, as it will usually help solve dependency/build issues or explain them in a slightly better way. rpmbuild -tb courier-foo.tar.bz2
I also highly recommend NOT building x86_64 stuff on a machine that has x86 libraries installed on it.
You need a separate build machine (or chroot) that is only x86_64 items and glibc.i686 and glibc-devel.i386 ...
or you will have much trouble building items from source and have mixed up library requirements ... if it builds at all.
On Wed, 14 Dec 2005 11:25:14 +0100 kadafax kadafax@gmail.com wrote:
I believe the problem comes from the mixed libraries living on the system (x86_64 and, for compatibility purpose, i386) and I didn't find a workaround on this. I'm near to switch to dovecot if it can handle quite large amount of users (500-1000 accounts). That would be bad because I think courier-imap is well doing its job. By the way, someone tolds me that courier-imap and RHEL4 (and clones) is a bad idea, someone can confirm? So:
Do you have libstdc++-devel package installed?
Vanja
Vanja Hrustic wrote:
On Wed, 14 Dec 2005 11:25:14 +0100 kadafax kadafax@gmail.com wrote:
I believe the problem comes from the mixed libraries living on the system (x86_64 and, for compatibility purpose, i386) and I didn't find a workaround on this. I'm near to switch to dovecot if it can handle quite large amount of users (500-1000 accounts). That would be bad because I think courier-imap is well doing its job. By the way, someone tolds me that courier-imap and RHEL4 (and clones) is a bad idea, someone can confirm? So:
Do you have libstdc++-devel package installed?
Vanja
yes, everything was there; maybe too much since the i386 versions were there too. As a result I restarted from the beginning, avoiding mixing arch (and that was not simple, ex: the server is a dell 2850 and their server's management tools are i386 only -weird-). I did encounter some problems for rpmbuild-ing the courier-authlib and courier-imap, I've posted some workaround in the courier-imap's mailing list. Really, I have the impression that courier-IMAP is badly supported on RHEL. kfx.
kadafax wrote:
yes, everything was there; maybe too much since the i386 versions were there too. As a result I restarted from the beginning, avoiding mixing arch (and that was not simple, ex: the server is a dell 2850 and their server's management tools are i386 only -weird-). I did encounter some problems for rpmbuild-ing the courier-authlib and courier-imap, I've posted some workaround in the courier-imap's mailing list. Really, I have the impression that courier-IMAP is badly supported on RHEL.
I am not sure what you mean by badly supported - its not supported at all, and therefore is not included in the distro. If a project wants to have their software run on a specific distro - the responsibility would fall on them, not the distro.
And you might want to keep in mind that you will be running this exercise everytime there is a bugfiz / securityfix released from courier-imap.
Karanbir Singh wrote:
kadafax wrote:
yes, everything was there; maybe too much since the i386 versions were there too. As a result I restarted from the beginning, avoiding mixing arch (and that was not simple, ex: the server is a dell 2850 and their server's management tools are i386 only -weird-). I did encounter some problems for rpmbuild-ing the courier-authlib and courier-imap, I've posted some workaround in the courier-imap's mailing list. Really, I have the impression that courier-IMAP is badly supported on RHEL.
I am not sure what you mean by badly supported - its not supported at all, and therefore is not included in the distro. If a project wants to have their software run on a specific distro - the responsibility would fall on them, not the distro.
that's what I mean: project's people responsibility. Why? courier-imap does not deserve this, imho.
And you might want to keep in mind that you will be running this exercise everytime there is a bugfiz / securityfix released from courier-imap.
Alternative? Cyrus uses its own mail store format. Dovecot don't seem to be viable for me: Of course I can be wrong but thing like a clear text password for ldap authentication (no re-binding with the provided credentials) is bad.
kfx.
On Sat, 2005-12-17 at 18:25, Karanbir Singh wrote:
I am not sure what you mean by badly supported - its not supported at all, and therefore is not included in the distro. If a project wants to have their software run on a specific distro - the responsibility would fall on them, not the distro.
What??? Why should a software project have any concern about the diversity of distributions? We'd all be better off it no one catered to non-standard quirks.
Les Mikesell wrote:
On Sat, 2005-12-17 at 18:25, Karanbir Singh wrote:
I am not sure what you mean by badly supported - its not supported at all, and therefore is not included in the distro. If a project wants to have their software run on a specific distro - the responsibility would fall on them, not the distro.
What??? Why should a software project have any concern about the diversity of distributions? We'd all be better off it no one catered to non-standard quirks.
re-read the original post. out-of-context, as you have quoted it, does look odd.
On Sun, 2005-12-18 at 10:19 -0600, Les Mikesell wrote:
On Sat, 2005-12-17 at 18:25, Karanbir Singh wrote:
I am not sure what you mean by badly supported - its not supported at all, and therefore is not included in the distro. If a project wants to have their software run on a specific distro - the responsibility would fall on them, not the distro.
What??? Why should a software project have any concern about the diversity of distributions? We'd all be better off it no one catered to non-standard quirks.
But who defines what is standard?
In this case, the upstream provider decides what goes into the distro and we clone the package selection. That is the standard.
That is the supported package list ... if something is not on that list, then it is up to either the customer OR the packager to support it in that case.
Why would the distro support something that is not in it?
All the packages that are included in the distro are tested together, compiled in a certain way, using libraries that are complementary, etc. One should try to use packages that are in the distro for that reason ... OR ... at least not complain about breakage and instability after they install other stuff that is self compiled.
-
Jim Perrin -
Johnny Hughes -
kadafax -
Karanbir Singh -
Les Mikesell -
Vanja Hrustic