Hello, I understand it's difficult to see which parts are written/generated by which software or person, so please let me explain: > checking for xlC_r... no > checking for xlC... no This output is generated when ./configure looks for a working C++ compiler. "But Dovecot has no source written in C++," you may reply. Yes, this check is not necessary; this is a known bug. (Surprisingly, this is a bug in libtool. It's already fixed in their development version.) So the above quotation is not relevant to your problems with AIX compiler. Actually, when ./configure searches for a valid C compiler, it tries only two names: "gcc" and "cc"; if the environment variable CC is set, its value is used instead. If no valid C compiler is found, ./configure aborts; it seems this wasn't your case. So I presume your C compiler (whatever its name is) was found. The other problem you mentioned: > checking sys/quota.h usability... no > checking sys/quota.h presence... no > checking for sys/quota.h... no > checking sys/fs/ufs_quota.h usability... no > checking sys/fs/ufs_quota.h presence... no > checking for sys/fs/ufs_quota.h... no > checking ufs/ufs/quota.h usability... no > checking ufs/ufs/quota.h presence... no > checking for ufs/ufs/quota.h... no > > (Because, of course, quota.h is in sys/jfs...) Well, the authors of davecot used the Autoconf macro in configure.in: AC_CHECK_HEADERS(sys/quota.h sys/fs/ufs_quota.h ufs/ufs/quota.h) Consequently, Autoconf generated a configure script which checks for these three header files. If it is not enough, the davecot authors can add more possible headers to the list. > So, instead of knowing the characteristics of the IBM C compiler and > AIX V5.x build environment, Autoconf is not responsible to "know the characteristics" of your compiler. Autoconf provides macros which help people write portable programs. But the developers of the project have to port and debug the project for a new platform. Autoconf performs whatever checks it is asked for. (Yes, if a set of checks is common enough, a new macro is introduced, but that's secondary.) The following: > checking for flock... no is also of that kind; see the corresponding source: dnl * after -lsocket and -lnsl tests, inet_aton() may be in them AC_CHECK_FUNCS(fcntl flock lockf inet_aton ... If the authors were aware of the possibility that flock might be in libhoxopoxo, they'd definitely use AC_SEARCH_LIBS([flock], [hoxopoxo]) or AC_CHECK_LIB([hoxopoxo], [hoxinit]) or whatever. In short, the developers on davecot are in the best position to port the program to your platform, if they are motivated for that task, and if thay have access to the platform. Sorry that we cannot have better news for you, Stepan Kasal _______________________________________________ Autoconf mailing list Autoconf@xxxxxxx http://lists.gnu.org/mailman/listinfo/autoconf
