Q: Why does GCC complain that it cannot open
Q: When I run the compiler it says it couldn't find header files
and/or libraries. But the headers and libraries are all there, so why
won't it find them?
Q: When I link my programs, ld.exe complains that it cannot open
crt0.o, although that file exists in the lib subdirectory....
Q: I tried to compile a program, but GCC complained about missing
socket.h. Can somebody please
mail me those headers?
Q: Why does GCC complain that it "cannot open -lgcc: File format
A: An error message about missing
-lstdcx usually means that
the linker cannot find the standard C++ library,
(it is truncated to
libstdcx.a on DOS and NT systems). Look into
lib/ subdirectory to see if it's there; if not, unzip it
libstdcxx.a exists but the linker still complains, you most
probably have a problem related to long file names on Windows 9X
libstdcxx.a exceeds the DOS 8+3 limits). For a quick fix, try
set LFN=y in the environment and see if that helps. If that
doesn't help, make sure you unpacked
gppNNNb.zip with an unzip
program which supports long file names.
This issue is further complicated if you use RHIDE v1.4, and is
described in full in the file
comes with the GCC distribution (and which you should have read before
the installation). Bottom line is that you need to add a line either to
rhide.env (the RHIDE distribution includes a file
rhide_.env which you should rename) or to
RHIDE_TYPED_LIBS_DJGPP.cc=stdcxx RHIDE_TYPED_LIBS_DJGPP.cxx=stdcxx RHIDE_TYPED_LIBS_DJGPP.cpp=stdcxx
When you add these lines, make sure neither they nor the
line have trailing whitespace, otherwise RHIDE will not recognize
DJGPP version 2.03 and later come with these lines in the
DJGPP.ENV file right out of the box.
RHIDE v1.4.7 and later solves this bug, so upgrade to the latest version if you can.
See C++ headers not found, for similar problems specific to C++ header files.
In general, if the compiler complains about missing files, you need
first to find out whether they at all exist on your system. For C
header files, look in the
include directory and its
subdirectories; for C++ header files, look in the
directory and its subdirectories; for libraries and the
file, look in the
lib directory. Some header files and object
files which are specific to a certain GCC version unzip into the
lib/gcc-lib/djgpp/X.YZ directory (where
X.YZ is the GCC
version number, e.g. 2.95), so look there as well.
If a header file indeed is not there, and you cannot find it in the
gppNNNb.zip distributions, it probably
means that this header belongs to a package which isn't part of the
basic DJGPP distribution. You need to find that package and install it.
It is important to understand that if a package is missing, getting hold
of the header files like
socket.h is not enough: you need the
library of the functions whose declarations and prototypes are in the
socket.h, you need a sockets library, such as
libsock; see DJGPP packages. For
graphics.h, you need GRX and the Borland-to-GRX
interface, BCC2GRX (rename the file
graphics.h); see BCC2GRX interface package.
If the header or the library does in fact exist on your machine, then in order for the compiler to find them, you should have the following variable set in your environment13:
and it should point to the correct path of the file
your system; the file itself is in djdev203.zip in
the DJGPP distribution. In the above example it is assumed to be in the
C:\DJGPP directory, but you should set it as appropriate for
Many of the problems with "missing" files, including the
highly-confusing message about
-lgcc ("File format not
recognized"), are usually caused by having the
set incorrectly. The following describes some problems with defining
DJGPP which pop up frequently on the DJGPP forum.
Sometimes, people make errors in their
AUTOEXEC.BAT that cause
the DJGPP variable to be defined incorrectly, or not defined at
all (some of the more common errors are listed below). To check what is
the actual setting, type from the DOS prompt:
set > env.dat
then examine the contents of the file
env.dat. You should see
there a line like this:
If a line such as this isn't there, you should investigate the cause for this (see below for some of the possibilities).
Many problems with setting DJGPP happen when people put excess
blanks around the
= character, which has the effect of defining
"DJGPP " (with the blank) which is not the same as "DJGPP" (without
blanks). You should make sure there are no such excess blanks, or DJGPP
won't find its files.
Another possible cause of DJGPP variable not being set is that you
invoke another batch file from your
AUTOEXEC.BAT before the line
that sets DJGPP. Make sure such batch files are invoked with the
CALL statement, because otherwise the subsidiary batch file will
never return to process the rest of
AUTOEXEC.BAT (that's a
"feature" of DOS batch file processing).
The code that processes
DJGPP.ENV assumes that this file resides
in the main DJGPP installation directory. If that assumption is wrong,
the compiler (and some other DJGPP programs) might fail to find some of
the files or auxiliary programs they need. Do NOT move DJGPP.ENV
to any other directory!
Note that if you run DJGPP on Windows/NT, you cannot use long
names of the directories in the pathname of
DJGPP.ENV when you
set the above variable in the environment; you should use their 8+3
aliases instead. That's because Windows/NT doesn't support the LFN API
for DOS programs, so the DJGPP startup code won't be able to find the
DJGPP.ENV file using its long pathname. For example, the
following setting won't work on Windows/NT because
Development is longer than 8 characters:
If the DJGPP variable is set correctly, then check the following possible causes of this misbehavior:
DJGPP.ENVin a way that invalidated some of the settings there; try restoring the original file from the distribution to see if that fixes your problems. Editing
DJGPP.ENVis not recommended, but if you must edit it, make sure you are familiar with its syntax in advance. The DJGPP server has a page with a description of the
The syntax of
DJGPP.ENV is also described in the DJGPP
which comes with the
gcc.exedriver to some other name. In this case, you should edit the file
DJGPP.ENVto add a section named after the new name of GCC, which is an exact duplicate of the section called
[gcc]. DJGPP start-up code uses this file to find environment variables which it should put into the environment before the
mainfunction is called, but it searches for the relevant variables using the actual name of the program, so when you rename the executable, it can't find its section and doesn't put the necessary variables into the environment.
One case where this might happen is if you install the GNAT (GNU Ada
Translator) package: its installation program alters the value of the
PATH environment variable so that when you invoke
you get GNAT's version of GCC, which searches header files in its own
directories. This can prevent GCC from finding header files of other
add-on packages, such as Allegro.
CONFIG.SYSis insufficient, so GCC runs out of available handles.
You should have at least
FILE=15 in your
on Windows. See details about FILES= directive.
-Bswitch to GCC. This overrides the default location of
crt0.oand if you follow
-Bwith a directory other than that where
crt0.oresides, the linker won't find it.
You should not need to use the
-L switches at all if
your installation is correct and the
DJGPP variable points to the
main installation directory, because GCC should be able to figure out
all the linker switches itself. If linking fails without explicit
-B, check out above for the possible causes.
|webmaster||delorie software privacy|
|Copyright © 2001 by Eli Zaretskii||Updated Apr 2001|