Node:Missing headers or libraries, Next:, Previous:No input files, Up:Compiling

8.2 GCC can't find headers or libraries

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 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 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:

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 and 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 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:


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: