Hi folks,
C_INCLUDE_PATH references are _not identical_ across the typical
platforms used for Mingw development (Win95, Win98, NT4). This is
probably not news; even so, I wasn't comfortable with not mentioning
it.
On 4 Jul 2001, at 10:26, the Illustrious Danny Smith wrote:
> --- Mumit Khan <khan@...> wrote: > On Tue, 3 Jul 2001,
> Paul Garceau wrote: > > > [ please trim when quoting ] > > The include
> path is controlled by the following: > > 1. -I switch supplied by the
> user. Highest priority. > 2. Environment variables -- C_INCLUDE_PATH,
> CPLUS_INCLUDE_PATH, > and OBJC_INCLUDE_PATH, for 3 different
> languages, > 3. Built in search path. This one first looks at paths
> that are > configured in compile time (eg., /usr/include on most
> Unix boxes), > and then relative pathname lookup given its current
> installation > directory. If Mingw gcc is installed in
> c:/gcc-2.95.2/bin/gcc.exe, > > then it will also look in
> c:/gcc-2.95.2/i386-mingw32/include for > example. > > Just use the
> -v option when compiling a file and you'll see where all > it
> searches. >
>
> That's how I thought it's supposed to work too. However, the
> C_INCLUDE_PATH and friends are actually searched *after* the built in
> path. CPATH works as I expected it to
>
> Recent GCC 2.95.3 gives same result.
(What follows looks like a bash prompt, and not a Windows prompt)
>
> $ set C_INCLUDE_PATH=d:\usr\local\include
> $ set CPATH=d:\usr\include
> $ touch test.c
> $ gcc -I. -v -c test.c
>
> Reading specs from
> d:\mingw-2.95.2\bin\..\lib\gcc-lib\i386-mingw32msvc\2.95.2\specs
> gcc version 2.95.2 19991024 (release)
> d:\mingw-2.95.2\bin\..\lib\gcc-lib\i386-mingw32msvc\2.95.2\cpp.exe
> -lang-c -v -I. -iprefix
> d:\mingw-2.95.2\bin\..\lib/gcc-lib/i386-mingw32msvc\2.95.2\
[Skipped specs output]
>GNU
> CPP version 2.95.2 19991024 (release) (80386, BSD syntax) #include
> "..." search starts here: #include <...> search starts here:
> .
> d:\usr\include
>
> d:\mingw-2.95.2\bin\..\lib\gcc-lib\i386-mingw32msvc\2.95.2\..\..\..\..
> \i nclude
>
> d:\mingw-2.95.2\bin\..\lib\gcc-lib\i386-mingw32msvc\2.95.2\..\..\..\..
> \i 386-mingw32msvc\include
> d:\mingw-2.95.2\bin\..\lib\gcc-lib\i386-mingw32msvc\2.95.2\include
> d:\usr\local\include
> End of search list.
Given that Danny was apparently referencing his output from a bash
shell of some sort, I am afraid that something is being lost in the
translation from the bash shell generated tool set to the Windows shell
generated tool set.
With that in my mind, I decided to run a few tests, and thought the
results were worth noting here.
Here's my test -- using the following source and a "Native Windows
Shell" (Win9x/command.exe, NT4/cmd.exe):
#include <stdio.h>
int main(int argc, char **argv)
{
printf("hello world, %s\n", argv[argc-1]);
}
In every OS noted below, I am using a Clean Install of the Mingw 1.0
distribution.
The point I hope to make is that somehow or another, the internal
generation of C_INCLUDE_PATH which occurs when running under an ms-dos
command prompt shell is getting munged (messed up, kluged, fubar, pick
your poison).
Danny Smith wrote:
> GNU CPP version 2.95.2 19991024 (release) (80386, BSD syntax)
> #include "..." search starts here:
> #include <...> search starts here:
> .
> d:\usr\include
>
> d:\mingw-2.95.2\bin\..\lib\gcc-lib\i386-mingw32msvc\2.95.2\..\..\..\..
> \i nclude
>
> d:\mingw-2.95.2\bin\..\lib\gcc-lib\i386-mingw32msvc\2.95.2\..\..\..\..
> \i 386-mingw32msvc\include
> d:\mingw-2.95.2\bin\..\lib\gcc-lib\i386-mingw32msvc\2.95.2\include
> d:\usr\local\include
> End of search list.
Please note the backslashes ("\").
Now for some (hopefully brief) comparisons:
NT4:
cmd.exe configuration --
Notes:
Path reference to Mingw "root" under NT4 is defined as:
"c:\mingw-1.0\bin".
Using .pif file to launch swdev.bat, which in turn opens Mingw specific
ms-dos prompt window (NT4 cmd.exe -x).
Excerpt from swdev.bat follows:
PATH "c:\mingw-1.0\bin";%PATH%
REM SET GCC_EXEC_PREFIX=c:\gcc-2.95.2\lib\gcc-lib\
cmd
-- end cmd.exe configuration
D:\src>gcc helloworld.c -ohelloworld.exe -I. -v
Reading specs from d:/mingw-1.0/bin/../lib/gcc-lib/mingw32/2.95.3-
4/specs
gcc version 2.95.3-4 (mingw special)
d:/mingw-1.0/bin/../lib/gcc-lib/mingw32/2.95.3-4/cpp0.exe -lang-c -v -
I. -iprefix d:\mingw-1.0\bin/../lib/gcc-lib/mingw32/2.95.3-4/
[Skip chunk of specs output]
-I/usr/local/include helloworld.c d:\TEMP\ccDcaaaa.i
(note unix references running under the command.exe shell -- is this a
relative path name? Is the DIR_SEPARATOR stuff causing this?)
GNU CPP version 2.95.2 19991024 (release) (80386, BSD syntax)
#include "..." search starts here:
#include <...> search starts here:
.
d:/mingw/lib/gcc-lib/mingw32/2.95.2/../../../../include
d:/mingw/lib/gcc-lib/mingw32/2.95.2/../../../../mingw32/include
d:/mingw/lib/gcc-lib/mingw32/2.95.2/include
\gcc-2.95.2/lib/gcc-lib/i386-mingw32msvc/2.95.2/../../../../include
\gcc-2.95.2/lib/gcc-lib/i386-mingw32msvc/2.95.2/include
End of search list.
Note:
DIR_SEPARATOR is correct for gcc.
Variance in slash types and additional include paths are added
for NT4. Can anyone tell me why this is so?
Win98:
d:\SRC>gcc helloworld.c -ohelloworld.exe -I. -v
Reading specs from /mingw/lib/gcc-lib/mingw32/2.95.3-4/specs
gcc version 2.95.3-4 (mingw special)
/mingw/lib/gcc-lib/mingw32/2.95.3-4/cpp0.exe
[Skip duplicated Define references (-D...)]
GNU CPP version 2.95.3-4 (mingw special) (80386, BSD syntax)
#include "..." search starts here:
#include <...> search starts here:
/mingw/lib/gcc-lib/mingw32/2.95.3-4/../../../../include
/mingw/lib/gcc-lib/mingw32/2.95.3-4/../../../../mingw32/include
/mingw/lib/gcc-lib/mingw32/2.95.3-4/include
End of search list.
Discrepancy:
Note that the C_INCLUDE_PATH for Win98 is different then the
C_INCLUDE_PATH generated for NT4. Specifically, the Win98 output does
not have the following reference:
\gcc-2.95.2/lib/gcc-lib/i386-mingw32msvc/2.95.2/../../../../include
\gcc-2.95.2/lib/gcc-lib/i386-mingw32msvc/2.95.2/include
Win95:
Win95 output [Win95 command.exe] -- (Yes, I still have that platform
floating around here, and no, the Win95 patch for Mingw 1.0 has not been
applied]:
--configuring command.com for Win95:
Using .pif file to launch mingw32.bat, which in turn opens Mingw
specific ms-dos prompt window (Win95 command.exe).
Excerpt from mingw32.bat follows:
PATH "c:\mingw\bin";%PATH%
REM SET GCC_EXEC_PREFIX=c:\gcc-2.95.2\lib\gcc-lib\
Notes:
Path reference to Mingw "root" under Win95 is defined in this test case
as "c:\mingw\bin" (see .bat excerpt above).
GCC_EXEC_PREFIX is not defined by either .bat file or by .pif file and
is instead "deferred" to Mingw Toolset.
C:\src>gcc hellow~1.c -ohellow~1.exe -I. -v
Reading specs from C:\MINGW\BIN\..\lib\gcc-lib\mingw32\2.95.2\specs gcc
driver version 2.95.2 19991024 (release) executing gcc version
2.95.2-mingw snapshot 20010329
C:\MINGW\BIN\..\lib\gcc-lib\mingw32\2.95.2\cpp.exe -lang-c -v -I.
-iprefix C:\MINGW\BIN\..\lib/gcc-lib/mingw32\2.95.2\
[Skipping specs output]
-I/usr/local/include hellow~1.c C:\WINDOWS\TEMP\cc9lrkgb.i
(hey!, there's that unix reference again...for command.com?)
GNU CPP version 2.95.2 19991024 (release) (80386, BSD syntax)
#include "..." search starts here:
#include <...> search starts here:
.
C:/MINGW/BIN/../lib/gcc-lib/mingw32/2.95.2/../../../../include
C:/MINGW/BIN/../lib/gcc-lib/mingw32/2.95.2/../../../../mingw32/include
C:/MINGW/BIN/../lib/gcc-lib/mingw32/2.95.2/include
End of search list.
What's wrong with this picture?
NT4 generates additional C_INCLUDE_PATH references beyond the
C_INCLUDE_PATH noted above. Internally, Win95 and Win98 generate
similar C_INCLUDE_PATH(s), but they are clearly _not_ identical.
Note:
DIR_SEPARATOR is correct for gcc.
source noted above compiled, linked and ran just fine.
Reading further down the output from the Win95 command noted above we
get:
-LC:\MINGW\BIN\..\lib\gcc-lib\mingw32\2.95.2
-LC:\MINGW\BIN\..\lib\gcc-lib
-LC:\MINGW\BIN\..\lib\gcc-lib\mingw32\2.95.2\..\..\..\..\mingw32\lib
-LC:\MINGW\BIN\..\lib\gcc-lib\mingw32\2.95.2\..\..\..
The above does not match the Win98 -L output, note the variance in
slash types. Win98 generates the forward slash ("/") whereas Win95 does
not.
Is there some "#ifdef" somewhere that forces this selection?
If so, then a possible fix might be to eliminate any differences
between how Win98 and Win95 internally generate the -L references noted
above.
Considering that cpp0.exe is kept in the lib\gcc-lib\mingw32\gcc-
2.95.3-4, and given what I've noted above, it does seem only logical
that maybe the -L handling is causing the problems with the Win95
directory, _not_ the DIR_SEPARATOR mutations...
Paul G.
------- End of forwarded message -------
|
