Libin Varghese wrote, quoting me:
>> Where have you installed MinGW?
>>
>> If you normalise the above path, (i.e. resolve out the `..' components),
>> it becomes:
>>
>> g:/mingw/3.4.5/include/sys/stat.h
>
> I have my mingw installed in f:/mingw . I have to replace
> g:/mingw/3.4.5/bin/ to f:/mingw .
So, it seems that the dependency tracking rules are messing up the path
resolution for the system headers. What does
gcc -v nul.c
display, for the include files search paths? (In my case, with MinGW
installed in `d:/usr/mingw-3.4.5', it looks like:
$ gcc -v nul.c
Reading specs from d:/usr/mingw-3.4.5/bin/../lib/gcc/mingw32/3.4.5/specs
[...]
#include "..." search starts here:
#include <...> search starts here:
d:/usr/local/include
d:/usr/mingw-3.4.5/bin/../lib/gcc/mingw32/3.4.5/../../../../include
d:/usr/mingw-3.4.5/bin/../lib/gcc/mingw32/3.4.5/include
End of search list.
GNU C version 3.4.5 (mingw special) (mingw32)
compiled by GNU C version 3.4.5 (mingw special).
[...]
(I'm running it under MSYS, hence the `$' prompt)).
> What I don't understand is from where is the configure script
> getting the path to mingw. Because if I change this one place from
> where configure is picking the mingw path, I don't have replace in
> all the .Po files.
These dependency rules are normally generated by running gcc itself,
not in the configure script, but by invoking a rule in the Makefile;
typically, the Makefile itself will be marked as dependent on a list
of `*.d' files, (each of which it `include's), and which themselves
are generated by a rule of the form:
%.d: %.c
<TAB>gcc -M $< > $@
If you run that gcc command yourself, what do you see? It should be
something like:
$ echo "#include <unistd.h>" > foo.c
$ gcc -M foo.c
foo.o: foo.c \
d:/usr/mingw-3.4.5/bin/../lib/gcc/mingw32/3.4.5/../../../../include/unistd.h \
d:/usr/mingw-3.4.5/bin/../lib/gcc/mingw32/3.4.5/../../../../include/io.h \
d:/usr/mingw-3.4.5/bin/../lib/gcc/mingw32/3.4.5/../../../../include/_mingw.h \
d:/usr/mingw-3.4.5/bin/../lib/gcc/mingw32/3.4.5/../../../../include/sys/types.h
\
d:/usr/mingw-3.4.5/bin/../lib/gcc/mingw32/3.4.5/include/stddef.h \
d:/usr/mingw-3.4.5/bin/../lib/gcc/mingw32/3.4.5/../../../../include/process.h \
d:/usr/mingw-3.4.5/bin/../lib/gcc/mingw32/3.4.5/../../../../include/getopt.h
(IMO, it is a bad idea to include system headers in dependency lists,
like this; a better way to generate the list is:
$ gcc -MM foo.c
(note the double `MM'), which restricts the dependency tracking to
a consideration of only project local headers, (or more accurately,
it excludes the system headers from consideration)).
Alternatively, if you don't want to be bothered by this level of
dependency tracking, you may be able to bypass it altogether, by
running the configure script with an option such as:
configure --disable-dependency-tracking
(check the output of `configure --help', to see if such an option
is supported; it is package specific, and may be called something
different, or may not be supported at all, but this specific form
is fairly common in GNU packages).
HTH,
Keith.
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
GnuWin32-Users mailing list
GnuWin32-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gnuwin32-users
