It all started when I've tried to compile PCP on Solaris using Sun's
compiler instead of the default CC: I was greated by messages like
checking dlfcn.h usability... no
checking dlfcn.h presence... yes
configure: WARNING: dlfcn.h: present but cannot be compiled
configure: WARNING: dlfcn.h: check for missing prerequisite
headers?
configure: WARNING: dlfcn.h: see the Autoconf documentation
configure: WARNING: dlfcn.h: section "Present But Cannot Be
Compiled"
configure: WARNING: dlfcn.h: proceeding with the preprocessor's result
configure: WARNING: dlfcn.h: in the future, the compiler will take
precedence
checking for dlfcn.h... yes
configure will finish and will generate the usable builddefs but
the messages are scary.
After some on and off attempts to get to the bottom of this I've
finally traced it to this particular bit in configure.in
dnl check if user wants their own C compiler
if test -z "$CC"; then
AC_PROG_CC
fi
cc=$CC
If CC in set in the environment then the whole set of checks is
skipped and, as side effect, the value of ac_objext is not set, so
when the header checks attempts to compile a test program to check
the usability of the header (new thing in autoconf 2.60 or whereabout)
it checks if 'conftest.' exists. Obviously it doesn't (not the lack of
object suffix), the message is printed and life goes on.
The problem is not limited to Solaris/Sun - you can get the same
result on Linux with
$ CC='gcc -m64' ./configure
IIRC the test was (in various) forms in configure from its inception
back in '99. I think it's time to kill it - AC_PROG_CC is capable and
willing to take CC from the enviroment, we're not going to loose any
functionality if it is removed and will actually gain support for
non-default compilers.
max
|