This is my warning.
warning : implicit declaration of function 'sqlglm'
The warning comes in a bi.pc file.
when i check the bi.c file.
it doesn't include
#include <sqlcpr.h>
#include <sqlca.h>
As .c file generate at compile time.
there is no need to edit .c file
i am using linux & gcc compiler,C.
This is an old question, but to be helpful to people who might stumble on it via search engine like me, the right answer is:
you have to add the following lines to your Pro*C source
EXEC SQL INCLUDE sqlca.h;
EXEC SQL INCLUDE oraca.h;
EXEC SQL INCLUDE sqlcpr.h;
The sqlca.h and oraca.h are required before sqlcpr.h can be included. A standard C header like stddef.h or stdio.h have to be included before these embedded SQL statements as they need to have size_t defined.
It is important to use the embedded SQL include statements instead of the C #include.
The EXEC SQL INCLUDE will copy the content of the header file into the generated C file. Therefore, it is not necessary to add the other include file paths of the Oracle client into the C compiler command line.
warning : implicit declaration of function 'sqlglm' shows up when function has been defined in some other header file, but has not been #included, or the function has not been defined at all. So, include the file which defines it or define it yourself.
Update
Use #include "sqlcpr.h" (in case sqlcpr.h is not in compiler's search paths and is in the same directory as the source file)
Related
Imagine that I have a C-project in the following folder:
C:\microcontroller\stm32\myProject
I have two important folders inside myProject:
- source => here are all my .c and .h files
- build => gcc will write all the object files in here
Note: as you can see, the backward slashes indicate that this is happening on a Windows pc.
The figure below gives an overview:
I will not display my complete makefile here, because that would lead us too far. The rules inside the makefile for all .c => .o files are similar. Let us just focus on the compilation of one specific file: fileA2.c:
--------------------- COMPILATION OF FILE fileA2.c -------------------
Building ./build/folderA/fileA2.o
arm-none-eabi-gcc C:\\microcontroller\\stm32\\myProject\\source\\folderA\\fileA2.c
-o C:\\microcontroller\\stm32\\myProject\\build\\folderA\\fileA2.o
-c
-MMD
-mcpu=cortex-m7
-...
-IC:/microcontroller/stm32/myProject/source/folderA
-IC:/microcontroller/stm32/myProject/source/folderB
Notice that the gcc call ends with two include flags: one for folderA and one for folderB. This enables gcc to use any of the header files from these folders (fileA1.h, fileA2.h or fileB1.h) if fileA2.c has an import statement.
Let us now consider the source code in fileA2.c. We assume that this file needs to include fileA2.h and also fileB1.h.
/*******************************/
/* SOURCE CODE fileA2.c */
/*******************************/
// Some include statements
#include "fileA2.h"
#include "fileB1.h"
// Code
...
These include statements work perfectly. The gcc compiler retrieves the files fileA2.h and fileB1.h in the given folders. But I noticed that the following does not work:
/*******************************/
/* SOURCE CODE fileA2.c */
/*******************************/
// Some include statements
#include "fileA2.h"
#include "folderB/fileB1.h"
// Code
...
The last include statement is a 'partial path' to the file. I get the error when compiling:
fatal error: folderB/fileB1.h: No such file or directory
How can I get gcc to handle this?
PS: It is not my own habit to use 'partial paths'. But they appear a lot in the libraries from the silicon vendor of my chip, so I have to live with it.
You specify two paths to look for includes other than the current directory for the source file:
-IC:/microcontroller/stm32/myProject/source/folderA
-IC:/microcontroller/stm32/myProject/source/folderB
You get the error because neither
C:/microcontroller/stm32/myProject/source/folderA/folderB/fileB1.h nor
C:/microcontroller/stm32/myProject/source/folderB/folderB/fileB1.h exists.
To address the error, you can add the following path:
-IC:/microcontroller/stm32/myProject/source
When using double-quotes to include a header file the compiler first looks in the same directory as the current file. If the header file is not found then it continues with the standard include search paths.
So when the compiler compiles the file source/folderA/fileA2.c the first directory the compiler will look for include files is the source/folderA directory. In the first example the fileB1.h will not be found there, but since you added source/folderB to the standard search path it will be found there as source/folderB/fileB2.h.
In the second example there is no folderB/fileB1.h file on source/folderA so the compiler will search the standard search path. When it comes to source/folderB it will again try folderB/fileB2.h (i.e. source/folderB/folderB/fileB2.h) and it will still not be found, nor will it be found anywhere else.
You need to add -IC:/microcontroller/stm32/myProject/source to be able to find folderB/fileB1.h.
Apart of the two correct responses you have received before this, you have the third chance to specify the path to the file in the #include directive from the curren directory, as with
`#include "../folderB/fileB1.h"
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'm not totally sure but this looks wrong:
I have a header file named fraction.h in which I store a fraction structure and the methods to handle it, one method is used to write a fraction in a file and in the signature of this function one argument is a FILE pointer.
fraction.h:
...
const Fraction * fraction_fwrite(const Fraction * f, FILE * file);
...
fraction.c:
#include <stdio.h>
#include "fraction.h"
...
Now when I try to compile a program that uses a fraction, I get an error,
here is what I have in my Makefile:
program_test: fraction.o program_test.o
and I include fraction.h in program_test.c of course.
but I keep getting this error :
fraction.h:34:54: error: unknown type name 'FILE'
someone could explain the different steps through which the compiler includes files ?
because <stdio.h> is in fraction.c so why does it strike this unfound-type error ?
should I include <stdio.h> in fraction.h ? which looks not really appropriate from my measly experience.
When you compile program_test, the compiler isn't looking at the other .c files, only the files you #include in the file you actually compile.
So, you either have to #include <stdio.h> in the test program, just like in fraction.c, or include it in the header file.
Even though the C standard says that the standard library files will not include each other, there is nothing saying that user defined files cannot do that. In fact it is usually much easier to use them if they do.
When the preprocessor processes a file, then it will copy the content of an included file into the file that is preprocessed. The reason why you don't get that error in fraction.c is that the content of stdio.h is included before fraction.h is included.
So the preprocessed file fragments.c looks like this:
stdio.h contents
fragment.h contents
fragment.c contents
Notice that the FILE definition will be included through stdio.h before it is referenced in fragment.h.
You should include stdio.h in fraction.h to get rid of this error.
Include stdio.h in program_test.c. If you dont include stdio.h in program_test.c (which includes fraction.h), the compiler doesn't know the definition of FILE used by fraction.h, and generates error.
And, you really should include stdio.h in fraction.h
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.
I'm trying to use a non-standard header file (http://ndevilla.free.fr/gnuplot). Its used in lots of codes in various different places on my computer. Currently I have to put the header file and the object file in every folder which its needed with the preprocessor directive:
#include "gnuplot_i.h"
In the file. Is there a way by which I can put the header file in one place so I can reference it like other standard header file. Cheers.
Compile with -I<directory>
E.g.
compile with -I/usr/local/gnuplot/inc.
Also it might be worth your reading up on include paths and the difference between:
#include <include_file.h>
and
#include "include_file.h"
Linking in an object file needs to be done explicitly the same way as a C file, which means (I believe) that you need a full path. However if you archive it into a proper library then you can use -l<library name> and -L<library path> instead. E.g.
gcc -I/usr/local/gnuplot/inc -L/usr/local/gnuplot/lib -lgnuplot -o my_prog my_prog.c
Most compilers have a flag -I that lets you add a directory of your choosing to the search path for include files.