Re: configure problems with the C for AIX compiler and AIXV5.x

[Stepan Kasal]

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