I have three .asn files. After these three files are compiled by the asn.1 compiler, each file has a corresponding directory in the output folder. In each folder, there are many C source files that were generated by the asn.1 compiler. There is always a .c file which has the same name as the .asn file (except the extension name, i.e. test.asn and test.c). In this file, some functions are defined; like asn_alloc, asn_free etc.
So, there are three files implementing the asn_alloc and asn_free functions. I'll use all the generated C files in my C project.
The problem is, the asn_alloc function is defined in three places. This is the reason I'm getting the compiler error:
multiple definition of function
How do I deal with this problem? I think that editing the generated source file is not a good idea.
This problem is specific to the ASN.1 Tool you are using. With some ASN.1 Tools (such as the one at http://www.oss.com), you can either include all of the .asn files in the same compilation so that one .c file is generated with all names disambiguated, or you can use the -prefix xxx option on each compilation where xxx is different for each ASN.1 compilation thus causing the generated names to be prefixed with xxx, therefore not conflicting.
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 am studying the C language, and I saw a new extension that I had not seen before.
What do files with the extension like library.h.in mean?
Is it as the simple header with extension ".h"? What's the difference?
These files are usually the input for autoconf which will generate final .h files.
Here's an example from PCRE:
#define PCRE_MAJOR #PCRE_MAJOR#
#define PCRE_MINOR #PCRE_MINOR#
#define PCRE_PRERELEASE #PCRE_PRERELEASE#
#define PCRE_DATE #PCRE_DATE#
Autoconf will replace all variables (#…#) with the respective values and the result will be a .h file.
Typically, a .h.in file is a header template that is filled in to become the actual header by a configure script based on the outcome of several tests for features present on the target platform.
Files ending with .in are typically template files used by a program called configure that generates a new file without the extension after substituting for variable expansions. I.e., if you're looking at a source tree that has files called, e.g. Makefile.in in the tree, then ./configure will generate a usable Makefile that can be used to "make" from source.
I have two sets of header files and .c files in my project i will only ever be including one of these headers but i want the option to quickly swap the header im including. Both header files have some declarations that are exactly the same but the implementations in the .c files are different. Basically what I need is way to tell the compiler to only compile the .c file that is associated with the header im including elsewhere in my program.
You could always specify the .c or .o file that you're going to link against at compile/link time for instance
gcc -o myexe file1.c/file1.o
or
gcc -o myexe file2.c/file2.o
you could even make this a different make directive if you have a makefile if you have the same header file but 2 different implementations. I would recommend just using 1 header file and changing the underlying implementation, no point in having 2 headers with similar declarations.
If both header files are exactly the same then you don't need to maintain two header files. You can keep only one copy. Whichever code includes the header file can include this single header file only.
You can always specify which .c file you want to compile while compiling. In gcc, you can mention the C file to be compiled in the command line. In Visual Studio, you can include the correct C file.
I guess you should maintain only one header file and include that in your code. Introduce a flag to the makefile to link which implementation to be linked. You have not mentioned what are you using to build.
Is there any way to get the absolute path of functions in map files? Map files support following format
0001:000016a0 func 00000001400026a0 f lib:func.o
Is there any way to get the absolute path of "func"
This may not be useful depending on your situation, but some linkers do not support having multiple object files with the same name in different directories. So if you give them some_directory/func.o and some_other_directory/func.o, only one of them will be linked. I know CodeWarrior does this.
In order to avoid this problem, I make sure that all of my object files have unique names. The convention I use is to include an abbreviation of the module name, for example, func_module.o. With that convention it is easy to identify the object file. Or if you need to do so programatically, any file searching technique will suffice.
Some versions of Visual Studio put all object files into a single directory, regardless of the organization of the .c and/or .cpp files, and will automatically append numeric suffixes to avoid conflicts. Figuring out which object file goes to which .c file requires reading the project file.
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.