I've inherited some code written for the (ancient) Microsoft C compiler 2.x. For each .c file, there is a .ec file of the same name. If I modify the C file and compile the code, nothing is different, but modifications to the .ec file take effect. Upon compiling, the .c file is updated to match the changes to the .ec file.
I've scoured the Internet for information about this compiler and I can't find anything. Why is there an EC file? It doesn't seem right to modify the EC files; I must be doing something wrong. I was expecting the .c file to contain the source code.
If anyone here used this compiler "back in the day," I'd appreciate any insight/information you can provide.
The extension .ec is the old C with embedded SQL extension, and is probably unrelated to Microsoft C. Your build system probably generates the .c file from the .ec file using a preprocessor. Look for exec sql statements in the .ec file embedded inside otherwise normal looking C code. Is there a relational database hanging around?
Unlikely to have anything to do with gcc preprocessor extensions.
A .ec is an expanded c file, basically the output of the preprocessor. See http://www.network-theory.co.uk/docs/gccintro/gccintro_36.html.
Use gcc with the -e to produce this file.
Related
I'm using Qt Creator running with the mingw C++ compiler to compile some C sources I obtained from an institution known as the NBIS.
I'm trying to extract just the code that will allow me to decode images encoded in the WSQ image format.
Unfortunately I'm getting messages that I have "multiple definitions" of certain functions
which is contradicted by a grep search, as well as complaints of undefined functions which are indeed defined in a single C file in each case.
I looked at the include files and these functions do have the word extern before them in the declarations.
As for the error messages of "multiple definitions" the linker says "first defined here" and only gives one object file in each case.
All C files have a C extension.
I should add that I'm getting strange messages when I look at the compiler outout like this:
Makefile.Debug:427: warning: overriding recipe for target 'debug/huff.o'
(it is true that I have two files called huff.c,but in different directories)
Are you by any chance including these .h in .cpp files (in addition to C files)? In which case you need to surround them by an extern "C" statement:
extern "C" {
#include "CHeader.h"
}
I was using "shadow-build" which creates a directory outside of the source file hierarchy
into which Qt places the makefile it generates from the project file, puts the object files
and so forth.
I deleted that directory and reran the Qt Build operation.
The problem went away.
Looks like it's a Qt bug.
I work for a group in which our test bucket has hundreds of .c source programs. The .c programs are fairly small and they all include the same 10 .h header files. These .h files are fairly large.
Each time we get a new library file to link our test programs to test, we run a script to recompile and run our test bucket against. The problem is that the compiling takes fairly long, especially if the environment is virtual.
Is there a way to compile the .h header files once, put in a separate object file and have those many .c source files link to said object file? I think this will speed up compiling time. I am willing to change/remove all the #include in the .c source programs.
Any suggestions to speeding up compile time is greatly appreciated.
Also, I should say that a script executes a makefile PER .c source test program! The makefile is not told to compile all programs in the current directory. Each test program is compiled into its own executable.
You could use precompiled header feature. See http://gcc.gnu.org/onlinedocs/gcc/Precompiled-Headers.html
You've asked further suggestions to speed up your compilation.
One way can be using ccache. Basically, ccache keeps a cache of the object files compiled so far and returns them (instead of re-compiling again over and over) when it recognises that the same source file is being compiled again.
Using it should be as simple as
Install ccache
Prefix your gcc/cc/g++ command with ccache
Rewrite your headers. Strip off all definition and leave in header. Strip off all implementation and put in new .c. Compile as library. Link with solution. Distribute library on runtime system.
If I understand correctly, the way libraries typically work is by using precompiled code in object files ( .so on Linux systems? ), while providing header files ( .h ) for use in projects.
What happens is when you compile, the #include <library.h> directive finds that header and pastes its contents in the source file being compiled. Then, once the source file is compiled, it is linked to the precompiled object file. That way, the library can be included in a huge number of projects without it needing to be compiled from source each time. The only part that must be recompiled when linking to a library is the ( relatively ) small amount of code in the headers, which essentially makes library functions and variables accessible to the source code.
All this means is that to drastically speed up compilation, your best bet is to take all of the functions out of the 10 .h files, and instead leave only the function prototypes in the headers. Once you have all of the functions in separate .c source files, you can compile them into an object file ( typically -c flag ). Then, whenever you need to compile a new program against the 10 headers you typically use, you can instead include your stripped down version of the headers, and link to the precompiled object. Since only the new code in the .c file has to be compiled, instead of all of the code in the headers, the process should be much faster.
I was looking at getting HTML-XML-Utils working on my computer and I noticed the .e filetype in the source tree. Running:
% file types.e
types.e: ASCII c program text
reveals some clues about it and its use in C files seems to be that of a header file.
Can anyone reveal some more information or history about this filetype? I've tried my best Google-foo but I cannot find anything.
I never heard of that file type in connection with C before, but after checking the files and the Makefile it seems to be variables and functions that are exported, therefore the .e extension.
They seem to be created by a special program (which comes with the package) called cexport whose manual page states:
cexport - create header file with exported declarations from a C file
I have a C project I'm importing to eclipse to work with. It was prewritten but not a C program, so I imported it as a C Makefile program. Actually for some reason the program was written with shell scripts which called the make in the appropriate directories, I added a Makefile that called the shell script, though I'll probably change it to use only make files.
Anyways the unusual thing is that I get exceptions on all the #define variables used in my C code. The variables are defined in a .h file which is included on the top of the C code, and the #include doesn't haev a warning. I can compile the code and run it without exception. Yet I still get dozens of errors where the #define values are used in the editor. The .h which defines the variables is in a different folder then the C code that throws the excception, but adding the folder with the .h into the C include path didn't do any good. Anyone know how I can get the editor to play nice with my #define variables?
Are you actually typing #DEFINE? It's supposed to be #define. C is case sensitive.
Here are some options to investigate the issue further:
Right-click your project in Eclipse, go to Properties -> C/C++ General -> Paths and Symbols -> Symbols. You can check the symbols defined there, maybe something is messing up the preprocessor there.
Add to your g++ command line the following option: -save-temps. This will output some intermediate compilation files. Check the .i or .ii files - these contain the preprocessed output. More information on this g++ option is here.
Also, it would be nice if you could give some more information about the actual errors/warnings.
How is the .h file included in the .c file?
#include <file.h>
or
#include "file.h"
These have different meanings in the preprocessor.
What is the error that you are getting? Is the .h file not found, causing the other errors?
I have a set of C files that I would like to use. Can I just copy them to my include directory, or do I have to compile them. I would think they would be compiled in the final binary.
You need to compile those C files if you want to use them.
To make use of what's in those C files, you'll nead a header file that declares what's inside them.
Those header files is what you'd put in your include folder, and you'll compile the C files together with your other C files. (Or you could make a library out of those C files)
Yes, they need to be compiled so that they are available at the linking step. C is not an interpreted language, so having the sources present in an include directory would do nothing for execution.
You can keep the source files at the same location. The include files will be in the include directory. You can use the compilation option -I./<include-file-directory> to specify from where to fetch the include files.
The final binary will be compiled version of all your source files which you give to the compiler. You have to explicitly specify every file to be compiled along the with final executable name.
In case you dont do so a default executable is created with the name a.out(i am assuming the platform to be linux and compiler to be gcc) in the directory where you compile.
Check the link for more details on compilation using Makefile.