While trying to compile Pike under MinGW I've encountered the problem that include files in /usr/local/include isn't found. First place of error is in the Gmp module.
configure:1574: checking for gmp.h configure:1584: gcc -E conftest.c >/dev/null 2>conftest.out configure:1580:17: gmp.h: No such file or directory configure: failed program was: #line 1579 "configure" #include "confdefs.h" #include <gmp.h>
If I manually add -I/usr/local/include it works, but what is the correct, general solution?
To find out why the loop in configure.in did not add /usr/local/include automatically. Did you perhaps set CPPFLAGS manually somehow? Does "Checking for /usr/local/include" appear in config.log at all?
"usr" doesn't appear in config.log at all. I can't find anything related to /usr/local/include in neither configure nor configure.in. ac_default_prefix is however /usr/local in configure.
Perhaps something gets confused by the fact that / is mounted as /usr.
$ mount C:\DOCUME~1\Nilsson\LOCALS~1\Temp on /tmp type user (binmode,noumount) C:\Program Files\MinGW\bin on /usr/bin type user (binmode,cygexec,noumount) C:\Program Files\MinGW\bin on /bin type user (binmode,cygexec,noumount) C:\Program Files\MinGW on / type user (binmode,noumount) C:\Program Files\MinGW on /usr type user (binmode,noumount) a: on /a type user (binmode,noumount) c: on /c type user (binmode,noumount) d: on /d type user (binmode,noumount) e: on /e type user (binmode,noumount) f: on /f type user (binmode,noumount) g: on /g type user (binmode,noumount) h: on /h type user (binmode,noumount) i: on /i type user (binmode,noumount)
And you are using a 2.5x autoconf, which is needed for sane config.logs? In that case, and if /usr doesn't appear at all, then it would mean that the prefix scan is completely bypassed, which should only happen if both LDFLAGS and CPPFLAGS have been set manually. It's the section of configure.in which begins with
if test $ldflags_is_set = yes -a $cppflags_is_set = yes ; then :; else for dd in \ [...]
You might want to run "sh -x configure" to find out exactly what happens here.
Mkay. Mast recently disabled those tests for pike_cv_sys_os=Windows_NT (by fixing a buggy test), which is why it's no longer working. So the question is did those tests break something for you mast, or can the os-test be removed?
They didn't really break anything, but I noticed that they added a bunch of include dirs that only exists on the unix side in an rntcl setup. Needless to say, such dirs aren't applicable.
My guess is that the Windows_NT test is a hack to disable that check in rntcl setups, but I haven't investigated the origin. If my guess is correct then it'd be better to instead check if $CC specifies rntcl or rntecl.
pike-devel@lists.lysator.liu.se