[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Gdb compilation argz.z No Such file or directory
From: |
Keith Marshall |
Subject: |
Re: Gdb compilation argz.z No Such file or directory |
Date: |
Fri, 2 May 2008 21:50:34 +0100 |
User-agent: |
KMail/1.9.1 |
Hi Mudeem,
This looks suspiciously like a cross-compiler installation problem.
On Friday 02 May 2008 20:32, Mudeem Siddiqui wrote:
> configure:5589: checking argz.h usability
Here, we see configure correctly invoking the cross-compiler, to check
that argz.h can be compiled:
> configure:5601: mipsel-uclibc-gcc -c
> -I/home/mudeem/QV140X/LINUX/KERNEL/linux-2.4.25/include conftest.c
And the outcome says "no, there's no such header in my search path":
> >&5 conftest.c:64:18: argz.h: No such file or directory
> configure:5607: $? = 1
>
> configure: failed program was:
> [...elided...]
> configure:5630: result: no
> configure:5634: checking argz.h presence
Yet here, we see an (unrelated?) preprocessor being invoked, to check
for presence of the same header:
> configure:5644: /lib/cpp conftest.c
And the outcome says "yes, this unrelated preprocessor can see that
header, in *its* search path":
> configure:5650: $? = 0
> configure:5670: result: yes
but that doesn't help you, because it belongs to a different compiler
tool set.
FWIW, here's what I see with my (correctly installed) i586-mingw32
cross-compiler, for the minimal test case:
$ cat configure.ac
AC_INIT
AC_PROG_CC
AC_CHECK_HEADERS([nonsuch.h])
$ ./configure --build=linux --host=i586-mingw32
...
configure:3240: checking nonsuch.h usability
configure:3257: i586-mingw32-gcc -c -g -O2 conftest.c >&5
conftest.c:51:21: nonsuch.h: No such file or directory
configure:3263: $? = 1
...
configure:3277: result: no
configure:3281: checking nonsuch.h presence
configure:3296: i586-mingw32-gcc -E conftest.c
conftest.c:18:21: nonsuch.h: No such file or directory
configure:3302: $? = 1
Note how, in my case, the cross-compiler is invoked a second time, to
check for presence of the header, and it confirms its nonexistence.
It seems like you need to find out why a preprocessor, which is
apparently unrelated to your cross-compiler, is being invoked for the
second phase of the test. The relevant section of config.log starts:
> configure:2959: checking how to run the C preprocessor
> configure:2994: mipsel-uclibc-gcc -E conftest.c
and that fails because you are apparently missing appropriate versions
of limits.h and assert.h, which are expected to be present for any
correctly installed compiler suite; when it does so fail, configure
then falls back to using /lib/cpp, which isn't what you want.
Regards,
Keith.