There may be "bugs" in the build routines for procmail-3.11pre7.
Unless, of course, these are misunderstood "features". :)
In INSTALL (procmail-3.11pre7), the following is written:
Intended configurable options in Makefile are:
the install-destinations and the LOCKINGTEST directories (you can
optionally use something like 'make BASENAME=$HOME install' instead).
it seems like the command-line macro definitions are not bequethed to
the make-launched makes, so,
make BASENAME=$HOME install
won't work as expected -- e.g., the manual-page installation target will
still be under /usr!
The workaround is to modify Makefile with the desired definition.
In some cases, the build routines overrule one's choice of compiler!
That this may happen is not at all clear.
I set a sh keyword parameter, CC, and bind it to the environment, and
expect *that* to be the macro definition of CC.
$ export CC
$ make install
The original Makefile doesn't look like it overrules it, so I assumed
this standard mechanism worked as expected.
But, some init/autoconf magic *rewrites* the Makefile, inserting the
macro definition "CC = cc". Sigh.
Apparently the build routine realized that my gcc installation was
broken, and overruled my choice.
I'd rather that poorly-chosen user-supplied specifications cause
build failure (which can then be investigated), rather than be
mysteriously ignored. The build routines are trying to be too smart!
Best regards to the procmail community,
I was building procmail-3.11pre7 for two platforms, SunOS 4 and