Q: Why does GCC complain that it cannot open -lstdcx?
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
header files netdb.h and socket.h. Can somebody please
mail me those headers?
Q: Why does GCC complain that it "cannot open -lgcc: File format
not recognized"?
A: An error message about missing -lstdcx usually means that
the linker cannot find the standard C++ library, libstdcxx.a
(it is truncated to libstdcx.a on DOS and NT systems). Look into
your lib/ subdirectory to see if it's there; if not, unzip it
from the gppNNNb.zip file.
If 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
to 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 gnu/gcc-2.95/readme.DJGPP which
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 DJGPP.ENV which
says this:
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 [rhide]
line have trailing whitespace, otherwise RHIDE will not recognize
these lines.
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 lang/cxx
directory and its subdirectories; for libraries and the crt0.o
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
djdevNNN.zip and 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
header. For 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 libbcc.h to
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:
set DJGPP=c:/djgpp/djgpp.env
and it should point to the correct path of the file DJGPP.ENV on
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
your installation.
Many of the problems with "missing" files, including the
highly-confusing message about -lgcc ("File format not
recognized"), are usually caused by having the DJGPP variable
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:
DJGPP=c:/djgpp/djgpp.env
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:
set DJGPP=c:/Programs/Development/Djgpp/djgpp.env
If the DJGPP variable is set correctly, then check the following possible causes of this misbehavior:
DJGPP.ENV in 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.ENV is 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 DJGPP.ENV syntax.
The syntax of DJGPP.ENV is also described in the DJGPP
Knowledge Base,
which comes with the djdev distribution.
gcc.exe driver to some other name. In this case,
you should edit the file DJGPP.ENV to 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 main
function 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 gcc,
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.
FILES= setting in CONFIG.SYS is insufficient, so GCC
runs out of available handles.
You should have at least FILE=15 in your CONFIG.SYS, more
on Windows. See details about FILES= directive.
-B switch to GCC. This overrides the default
location of crt0.o and if you follow -B with a directory
other than that where crt0.o resides, the linker won't find it.
You should not need to use the -B or -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
-L or -B, check out above for the possible causes.