Q: I installed all the packages, but GCC complains it can't find
_string.h and other C++ headers. Where can I
find those header files?
Q: GCC complains about being unable to find
Regex.h and other header files which start with a capital letter,
and I indeed don't see them in my
lang/cxx/ directory. Where are
Q: My C++ program needs header files whose filenames exceed the 8+3
DOS filename restrictions, like
streambuf.h, and GCC cannot find those files. How in the world
can I write portable C++ programs??
A: All C++ include files are packaged as part of the GNU C++ compiler distribution zip file,
so if you didn't install it, GCC won't find them. Files whose names
usually start with a capital letter, on MS-DOS have an underscore
_ prepended so they can be distinguished from
regex.h and the like under case-insensitive DOS. Change
_String.h in your source, and GCC will find them. The same goes
for the header
iostreamP.h--you should use
instead. If you don't have the underscore _ on your keyboard, you
might find using
strclass.h instead of
Another possibility to handle header files like
Complex.h in a
portable way is to pass the
-remap switch (supported by GCC 2.8.0
and later) to the pre-processor; see the
cpp docs and the
readme.DJGPP file in the GCC distribution, for more info about
The most probable cause of problems with header files whose names exceed
the DOS 8+3 limits is that you are compiling on Windows 9X, but the
Long File Names (a.k.a. LFN) support is disabled. DJGPP v2.01
comes with LFN disabled by default on the
DJGPP.ENV file. To
enable it, set the environment variable
If the problems with long names of header files aren't solved by this,
it is possible that you unpacked the DJGPP distribution with a program
which doesn't support long file names. The solution is to install DJGPP
again using a different unzip program.
from the DJGPP sites, is one possibility.
Some users copy the DJGPP directories after unzipping to another place
on their disk, or backup and restore them. If this is done by some
program that doesn't support long file names, the compiler won't be able
to find header files such as
strambuf.h. Editing the directory
with some disk-editing tool that doesn't support Windows 9X style long
file names can also cause such loss of long file names: when Windows 9X
starts up, it checks whether the long file names and their 8+3 aliases
are in sync, and if they aren't, the long file names are deleted from
the directory, leaving you only with the short file names such as
dir *.h to see what are the long file
names in the directory; the long names are printed on the right side of
the file listing, and the short aliases on the left side, like this:
stream h 1,925 12-26-95 8:07p STREAM.H stream~1 h 17,020 01-24-96 2:11a streambuf.h
(The files' date, time, and size might be different in your case.) The easiest solution for these cases is to remove the entire DJGPP installation, and unzip everything again.
Another possible cause for lack of support for long file names is that you switch to the so-called "DOS Mode" when running DJGPP programs from Windows 9X. This unloads from memory most of Windows, including the VFAT Filesystem module that supports the LFN API used by DJGPP to access long file names. The solution is to make sure your DOS box's Properties don't force a switch to "DOS Mode".
If you have problems with header files with long filenames, and you run
under Windows NT, it usually means that you used an unzip program which
supports long file names on NT; unzip again using a DOS unzip program,
unzip32.exe that is available from the DJGPP sites.
Alternatively, you could install an LFN driver for Windows NT, see
LFN driver for NT,
earlier in this FAQ.
Another possible cause for problems with C++ include files is that your
source file has a
.c extension. GCC then thinks that this is a C
program and doesn't instruct the pre-processor to search the include
directories specific to C++. Rename your file to
.cpp extension, or call GCC with the
-x c++ switch, and
the header files will be found. A full list of extension rules which
GCC uses to determine the source language can be found in the list of language-specific suffixes, elsewhere in this FAQ.
|webmaster||delorie software privacy|
|Copyright © 2001 by Eli Zaretskii||Updated Apr 2001|