www.delorie.com/djgpp/v2faq/faq051.html | search |
| Previous | Next | Up | Top |
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"?
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 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.
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 environment(Note: The example uses Unix-style forward slashes, but DOS-style backslashes can also be used.):
set DJGPP=c:/djgpp/djgpp.envand it should point to the correct path of the file DJGPP.ENV on your system; the file itself is in djdev201.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.
Most 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.lstthen examine the contents of the file env.lst. You should see there a line like this:
DJGPP=c:/djgpp/djgpp.envIf 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.envIf the DJGPP variable is set correctly, then check the following possible causes of this misbehavior:
stat
in some cases. The exact reason of the failure has been identified, and the library which comes with DJGPP v2.01 includes a version of
stat that works around that problem, so the linker from v2.01 is free of this bug, and upgrading will solve this. Another solution would be to upgrade your Novell software; version 4.x
is reportedly free of this problem, even if you use DJGPP v2.0.
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.
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.
webmaster donations bookstore | delorie software privacy |
Copyright ⌐ 1998 by Eli Zaretskii | Updated Sep 1998 |
You can help support this site by visiting the advertisers that sponsor it! (only once each, though)