C warning: implicit declaration of function - c

Yes, this question has been asked many times, and I've been looking and reading forums, and SO posts, but the answers are all unrelated (or so they seem) to this one. So, I have this main file :
-- sgbd_server.c --
#include "sgbd_server.h"
/**
* Open server pipe and return handle. -1 = error
*/
int open_server_pipe() {
return pipe_open(FIFO_NAME, O_RDONLY, S_CON_COLOR);
}
/**
* Close server pipe
*/
void close_server_pipe(int fd) {
pipe_close(fd, FIFO_NAME, S_CON_COLOR);
}
int main(int argc, char *argv[]) {
int pipe_fd;
pipe_fd = open_server_pipe();
if (pipe_fd == -1) {
perror("Cannot open pipe");
}
close_server_pipe(pipe_fd);
exit(EXIT_SUCCESS);
}
Then the header files :
-- sgbd_server.h --
#include "common.h"
#define FIFO_NAME "./sgbd_server_pipe"
#define BUFFER_SIZE PIPE_BUF
#define S_CON_COLOR 1 /* C_COLOR_RED */
-- common.h --
#include <unistd.h>
#include <stdlib.h>
#include <stdio.h>
#include <string.h>
#include <fcntl.h>
#include <limits.h>
#include <sys/types.h>
#include <sys/stat.h>
#include "console.h"
#define CLIENT_FIFO_PREFIX = "./sgbd_client_"
int pipe_open(char *f, int mode, int color);
void pipe_close(int pipe_fd, char *f, int color);
The two functions pipe_open and pipe_close are defined in pipe.c and are basically returning 0 and void. This last file is compiled separately in the Make file.
I'm not a guru at making Make files, but for the sake of this question, here it is :
SERVER = sgbd_server
CLIENT = sgbd_client
CC = gcc
C_FLAGS = -Wall -I.
LINKER = gcc
L_FLAGS = -Wall -l pthread -Wall -I.
RM = rm -f
client: sgbd_client.o pipe.o console.o
#echo -n "Building client... "
#$(LINKER) $(L_FLAGS) -o $(CLIENT) sgbd_client.o pipe.o console.o
#echo "Complete!\n"
server: sgbd_server.o pipe.o console.o
#echo -n "Building server... "
#$(LINKER) $(L_FLAGS) -o $(SERVER) sgbd_server.o pipe.o console.o
#echo "Complete!\n"
sgbd_client.o: sgbd_client.c
#echo -n "Refreshing client sources... "
#$(CC) $(C_FLAGS) -c sgbd_client.c
#echo "Done!"
sgbd_server.o: sgbd_server.c common.h
#echo -n "Refreshing server sources..."
#$(CC) $(C_FLAGS) -c sgbd_server.c common.h
#echo "Done!"
pipe.o: pipe.c
#echo -n "Refreshing pipe sources..."
#$(CC) $(C_FLAGS) -c pipe.c
#echo "Done!"
console.o: console.c
#echo -n "Refreshing console sources..."
#$(CC) $(C_FLAGS) -c console.c
#echo "Done!"
clean:
#echo -n "Cleaning up executables and object files... "
#$(RM) $(SERVER) $(CLIENT) *.o
#echo "Ok\n"
** NOTE ** : the file console.c and implements some functions to control I/O on the console, nothing fancy. As you see, it is also compiled separately.
Now, when I type make client, all is well and birds are signing, etc. etc. But when I type make server, it spits out
sgbd_server.c: In function ‘open_server_pipe’:
sgbd_server.c:7: warning: implicit declaration of function ‘pipe_open’
sgbd_server.c: In function ‘close_server_pipe’:
sgbd_server.c:14: warning: implicit declaration of function ‘pipe_close’
I'm running GCC on a Linux amd64 if it makes any difference (I doubt it).
Now, why would it warn me about that? The two functions are declared in common.h, which is included in sgbd_server.h... What am I missing here?
Thank you for your time!
** UPDATE **
Thank you everyone for your suggestion. I did try to find if there would be a file common.h somewhere else in my include path that would be included somehow... While I failed to find any that would have slipped in the compilation process instead of the local common.h (sig) I found some .ghc files sitting in my source folder. Since they are not cleaned by make clean, I deleted manually those files. Guess what? No warning. What are those files and why are they created?

For a start, I don't think it's a good idea to be giving common.h to the compiler in the makefile:
#$(CC) $(C_FLAGS) -c sgbd_server.c common.h
This would be better as just:
#$(CC) $(C_FLAGS) -c sgbd_server.c
Header files are usually incorporated with just an #include. You appear to be telling the compiler to try and compile common.h as a standalone C file. That's one difference between the client and server compile commands and you should fix it.
The only other thing I can suggest is that you may not be getting the header files you think you're getting. Start by putting the line:
#error Urk! in common.h
at the top of your common.h and ensure the build fails there.
If not, then that file is coming from somewhere else. You may also want to do the same thing with your sgbd_server.h file as well.
Based on your edit:
I found some .ghc files sitting in my source folder. Since they are not cleaned by make clean, I deleted manually those files. Guess what? No warning. What are those files and why are they created?
These are, assuming ghc was a typo and you meant gch, pre-compiled headers generated by gcc, at least in part to speed up the compilation process. Rather than having to process a header file many times during a build (once per source file that includes it), pre-compiling it once and using the pre-compiled version is a lot more efficient.
I think this was most likely cause by the fact that you included common.h on your compiler command line when you did the server. By default, header files given directly to gcc will be turned into pre-compiled header files and used in preference after that point. To test this, I created a qq.h file and executed gcc qq.h and out popped qq.h.gch.
It's quite likely, given that deleting them solved your problem, that these files were somehow causing your issues (be that the presence of pre-compiled headers older than the real headers or something else entirely). There's a good chance that your compile line:
#$(CC) $(C_FLAGS) -c sgbd_server.c common.h
would first compile the server program, including the old precompiled header, then make a new precompiled header out of the newer header file.
That's probably why a change to common.h had no (immediate) effect. You would have to make ; touch common.h ; make to ensure the newer pre-compiled header file was used in the server program.
Whether you want to track it back to the root cause and get a proper explanation is a matter of taste - there's a school of thought that you should sometimes just record how you fixed it and not worry too much, lest you become entangled in the very nature of reality itself.
Not me of course, I'm the personality type that will attempt to track my problems back to the individual sub-atomic particle that caused it, but sometimes pragmatism requires me to let it go :-)

observations: you have an = in a #define which I suspect you don't mean to have there
#define CLIENT_FIFO_PREFIX = "./sgbd_client_"
should perhaps be
#define CLIENT_FIFO_PREFIX "./sgbd_client_"
comments: I've occasionally witnessed strange behavior from compilers when a prototype contains formal parameter names (in addition to the mandatory types) and the definition of the function uses different formal parameter names. ie. in your pipes.c Does you pipes.c
include common.h?
Also, conditional guards #ifndef headerfilename #define headerfilename #endif
are a good practise, but that is not directly related to your problem.
.PMCD.

I suspect you might have another file called common.h that's getting included instead of the file you expect. I copy and pasted your files and it compiled with no warning.

The includes in the files you posted look like they should work. A few ideas what else could be wrong:
Does common.h or console.h try to include sgbd_server.h, so that you end up with circular includes?
Do you use include guards (or even other #ifdefs) and maybe mixed them up somewhere, so that one of the files is excluded unintentionally?
Do you have another common.h somewhere in you include path that might get included instead of the one that you intended?

Related

Shared library and rpath

I cannot make rpath work properly and make my binary to search for the library in the specified folder:
I have 3 very simple files:
main.c
#include <stdio.h>
#include <func.h>
int main() {
testing();
return 1;
}
func.h
void testing();
func.c
#include "func.h"
void testing(){
printf(testing\n");
}
Then I proceed to create a shared library as it follows:
gcc -c -fpic func.c -o ../release/func.o
gcc -shared -o ../release/lib/lib_func.so ../release/func.o
And then compile the program:
gcc main.c ../release/lib/lib_time_mgmt.so -Wl,-rpath=/home/root/ -o ../release/main
I receive the next warning:
main.c:7:2: warning: implicit declaration of function ‘testing’ [-Wimplicit-function-declaration]
testing();
But besides it, the program works fine.
However, my problem is that if now I want to move the library to /home/root (as specified in rpath) it does not work and the library is still searched only in the path specified when I compiled the main.c file which is ../release/lib/lib_time_mgmt.so
What am I doing wrong?
EDIT: After accepting the answer, I leave here the exact line as I used it and made it work for whoever might find it useful:
gcc main.c -L/home/root -Wl,-rpath,'/home/root/' -l:libtime_mgmt -o ${OUT_FILE}
Note: the rpath was used with the path betwen simple '. Not sure if that was the reason why it was not working before, but it worked this way now.
rpath is not used at compile time, but rather at link/runtime... thus you probably need to use both of these:
-L /home/root - to link correctly at build time
-Wl,-rpath=/home/root - to link correctly at run-time
You should use the -l ${lib} flag to link with libraries, don't specify their path as an input.
In addition to this, convention states that the libraries are named libNAME.so - e.g:
-l func will try to link with libfunc.so
-l time_mgmt will try to link with libtime_mgmt.so
Once you've addressed the above points, try the following:
gcc main.c -L/home/root -Wl,-rpath=/home/root -lfunc -ltime_mgmt -o ${OUT_FILE}
As a final point, I'd advise that you try not to use rpath, and instead focus on installing libraries in the correct places.
Unrelated to your question, but worth noting. Your use of #include <...> vs #include "..." is questionable. See: What is the difference between #include <filename> and #include "filename"?

Is it possible to use .d file to compile all dependent c files?

I'm new to make ifle
I want to test certain function in my main. this function inside c files which has a LOT of dependencies that I cant even track
Is it possible to use the .d file for that .c file to compile my main with it to get this function working in my small application and the .d file gets all dependencies ?
I was thinking if it is possible to do something like
mymain.o : requiredfunctions.d mymain.c
You seem to misunderstand the relationship between source files, header files, object files and executable files.
Suppose we have several functions:
void alpha();
void beta();
void gamma();
void delta();
...
Each is declared in a header file (alpha.h) and defined in a source file (alpha.c). And suppose for now that these functions are independent; they do not call each other. Compiling one of them (to produce an object file) is easy:
gcc -c beta.c -o beta.o
(The "-c c -o o" is just a coincidence. The -c means "build an object file", and the -o means "here's how to name the result".)
We also have a function void octopus() that calls all of them. We declare it in a header, octopus.h:
// octopus.h
void octopus();
and define it in a source file, octopus.c:
#include "alpha.h"
#include "beta.h"
...
#include "omega.h"
void octopus()
{
... // calls alpha(), beta(), etc.
}
Producing the object file is easy:
gcc -c octopus.c -o octopus.o
Now suppose we have a file, mymain.c, which contains main() and invokes some functions:
#include "alpha.h"
#include "beta.h"
int main()
{
alpha();
beta();
return 0;
}
Building the object file mymain.o is easy:
gcc -c mymain.c -o mymain.o
Building the executable mymain is slightly more difficult:
gcc mymain.o alpha.o beta.o -o mymain
If all of this is clear, then I can attempt to guess what you want. You want main() to call octopus(), and you want Make to build the executable for you even though you do not know the list alpha, beta,... omega, is that right?
EDIT: If you have the file octopus.d:
octopus.o: octopus.c alpha.h beta.h ... omega.h
you can turn it into the list of required object files:
alpha.o beta.o ... omega.o
by any of a number of methods. You could use sed from the command line:
sed 's/.*\.c //;s/h /o /g' octopus.d
or within a makefile you could use Make's text-manipulation functions:
OBJECTS := $(subst .h,.o,$(filter %.h, $(shell cat octopus.d)))
This is the standard way of doing it:
foo.o : foo.c foo.d
cc $< -o $# -MF $(#:.o=.d)
touch $(#:.o=.d)
touch $Q
foo.d : ;
include foo.d
Not guaranteed to work as it is, just typed in without testing, but you get the idea.
Make sure that the compiler really produces the .d file in the proper format, further options might be necessary for your compiler. Some assemblers can also produce deps in the same way as compilers.
What's happening:
We define the dep file as a secondary target. If it's missing or out
of date, the recipe will be executed.
After invoking the compiler, we touch first the dep file then the
object. This fixes two issues: some compilers can't generate deps,
and some set the dep file date to later than the object date. That
would trigger unnecessary compilations.
The empty recipe tells make that the file is generated by some
other recipe, no need to panic when it's not there.
And finally, we include the dep file.

When I compile in C I have an error of imports in header files

I got the next error when I compile my project.
./PC.h:15:12: error: unknown type name 'InstructionMemory'
PC *new_pc(InstructionMemory *memoria);
^
./PC.h:17:1: error: unknown type name 'InstructionMemory'
InstructionMemory *get_memory(PC *programCounter);
^
2 errors generated.
In file included from main.c:5:
./InstructionRegister.h:7:36: error: unknown type name 'BankRegister'
int opera(InstructionRegister *IR, BankRegister *bank);
But this don't makes me sense, I look at the files and they are headers files, so I know that you can not use #include into headers file. So I don't know what I'm doing wrong.
There is the content of my PC.h file:
typedef struct PC PC;
PC *new_pc(InstructionMemory *memoria);
int getpc(PC *programCounter);
InstructionMemory *get_memory(PC *programCounter);
char *fecth(PC *programCounter);
char *linea_actual(PC *programCounter);
I use the next makefile to compile:
CC = gcc
CFLAGS=-I
DEPS = ALU.h InstructionRegister.h Rebasing.h BankRegister.h MemoryInstruction.h ControlUnit.h PC.h
run: exect
./exect $(EX)
%.o: %.c $(DEPS)
$(CC) -c $< $(CFLAGS)
exect: ALU.c InstructionRegister.c Rebasing.c BankRegister.c MemoryInstruction.c main.c ControlUnit.c PC.c
gcc -o exect InstructionRegister.c Rebasing.c BankRegister.c MemoryInstruction.c main.c ControlUnit.c PC.c -I.
clean:
rm -f *.o
so I know that you cannot use #include into headers file.
You are mistaken. You can, and often should and want to, use several include directives in your header file.
A typical small C project (e.g. less than a hundred thousands lines of C code in total) often would have a single common header file, e.g. myheader.h, typically starting with an include guard and several system includes, so like
#ifndef MYHEADER_INCLUDED
#define MYHEADER_INCLUDED
// some system includes
#include <stdio.h>
#include <stdlib.h>
/// your type declarations
enum foo_en { /* blablabla */ };
struct bar_st { /* blablabla */ };
typedef struct bar_st Bar;
/* etc... */
/// your global functions
extern int myglobfun(int, int);
/* etc...*/
/// your global variables (have only a few of them)
extern Bar*my_bar;
/* etc... */
#endif /*MYHEADER_INCLUDED*/
This is just one possibility of organizing a project. Some people prefer to have many header files and explicitly #include system headers before some of their own headers in every of their translation units (e.g. C source files).
The advantage of having a single common header is that the Makefile is simple to code, and you might even precompile your common header. A disadvantage is that any change (e.g. adding a field in a common struct) in that header forces make to recompile everything (not a big deal for a small project).
Alternatively you could have many header files, then be sure to use include guards (in the single common header case it is actually useless but does not harm) in them, and to define a discipline regarding multiple inclusion. Often, a header file would itself include other needed header files, or else check that they have been included, e.g. with
// file "myheaderone.h"
#ifndef MYHEADERONE_INCLUDED
// check that "myotherheader.h" has been included
#ifndef MYOTHERHEADER_INCLUDED
#error myotherheader.h should have been #include-d
#endif
//// etc
Alternatively you might code #include "myotherheader.h" near the beginning of myfirstheader.h
If you have multiple headers, you need a complex Makefile and you'll rather generate the dependencies, see this. It uses some preprocessor options to gcc like -M and friends.
BTW, your Makefile is wrong. Don't hardcode cc in it (but use $(CC)). Be sure to ask GCC for all warnings & debug info (e.g. CFLAGS= -Wall -g). Learn about GNU make catalog of rules by running make -p. And your CFLAGS= -I is really wrong, you might want CFLAGS= -I. -Wall -g since -I should always be followed by a directory.
PS. If using gcc take the habit of always passing -Wall to it. Very often (and certainly in your case) you also want -Wextra (to get even more warnings; remember the compiler warnings are your friends and you should improve your code till you have none of them) and probably -g (to be able to use the -g debugger). For benchmarking purposes ask the compiler to optimize (e.g. with -O1 or -O2 -mcpu=native).
Be aware of the -H preprocessor option: it is asking gcc to show every included file. Sometimes (e.g. to debug some nasty macro) you want to see the preprocessed form of a translation unit, use gcc -C -E to get it.

Include gsl_type.h. File not found

It seems to be a common issue but I can't wrap solve this problem.
I have some .c code that I compile using a makefile. The goal is to create a shared object (.so) so that I can run the C code from R.
Here is my makefile:
obs = R_wrapper.o G.o develop.o utilities.o
CFLAGS = -arch x86_64 -std=gnu99 -I/Library/Frameworks/R.framework/Resources/include -I/Library/Frameworks/R.framework/Resources/include/x86_64 -DNDEBUG -I/usr/local/include -fPIC -g -O3 -c
LFLAGS = -arch x86_64 -std=gnu99 -dynamiclib -Wl,-headerpad_max_install_names -undefined dynamic_lookup -single_module -multiply_defined suppress -L/usr/local/lib -O3 -lgsl -lm -lgslcblas
R_wrapper : $(obs)
$gcc $(LFLAGS) $(obs) -o R_wrapper.so
R_wrapper.o : R_wrapper.c constants.h develop.h G.h
$gcc $(CFLAGS) R_wrapper.c
G.o : G.c G.h constants.h utilities.h develop.h
$gcc $(CFLAGS) G.c develop.c
develop.o : develop.c develop.h G.h constants.h
$gcc $(CFLAGS) develop.c
utilities.o : utilities.c develop.h
$gcc $(CFLAGS) utilities.c
It works fine on the computer in my lab but it doesn't work on my personal computer. What causes this issue is these two lines at the beginning of my R_wrapper.c.
#include </opt/local/include/gsl/gsl_randist.h>
#include </opt/local/include/gsl/gsl_rng.h>
I have tried to move these files around and give different paths, put the files in the gal_type.h files in the same directory as my R_wrapper file, I have tried to rename my directories so that the path is more conventional but the OS did not give me the right to rename opt into usr (which probably makes obvious sense). I haven't created the makefile and don't fully get it. I would suppose I'd need to modify the path after the -I argument somewhere in CFLAGS OR LFLAGS.
EDIT 1
I changed R_wrapper.c on my lab computer to get rid of the whole path in #include <...>. Compilation failed as #Beta predicted. Then, I changed my makefile to add -I/opt/local/include/gsl to CFLAGS. I don't know what you mean by Verify that the makefile still works. I tried to compile with my edited makefile on my lab computer and it failed. I then re-edited my makefile changing -I/opt/local/include/gsl to -I/usr/local/include/gsl because on my lab computer the gsl folder is at /usr/local/include/gsl. -I/opt/local/include/gsl is the location of the gsl folder on my computer. So I am stuck here in your procedure.
Edit 2
I moved my gsl folder around my computer trying to include from different paths. And some interesting stuff happen. For example when I put my gsl folder in Users/remi/Documents/Biologie/programing/C/ and write (in CFLAGS)
-I/Users/remi/Documents/Biologie/programing/C/
I get this error:
R_wrapper.c:43:10: fatal error: 'gsl_randist.h' file not found
#include <gsl_randist.h> // goal.
When I write (in CFLAGS)
Users/remi/Documents/Biologie/programing/C/gsl
I get this error message:
"In file included from R_wrapper.c:43: /Users/remi/Documents/Biologie/programing/C/gsl/gsl_randist.h:22:10: fatal error:
'gsl/gsl_rng.h' file not found
#include <gsl/gsl_rng.h>"
Transferring comment to answer
Judging from the message about gsl/gsl_rng.h not being found that is mentioned in Edit 2, you should be writing
#include <gsl/gsl_randist.h>
(with the path prefix of gsl/ before the header name) in your source code. This is a common convention. You then specify in the -I option the name of the directory containing the gsl subdirectory that contains the gsl_*.h headers. In your Edit 2, you say you put the gsl directory into /Users/remi/Documents/Biologie/programing/C/, so you are then correct to use:
-I/Users/remi/Documents/Biologie/programing/C/
on the command line as you tried.
You should read the documentation, and if it says write either of these:
#include <gsl/gsl_randist.h>
#include "gsl/gsl_randist.h"
then that is what you should write in your code, because (as you've discovered the hard way) if you don't, it won't work.
Beta's answer also states
In general it's a bad idea to write paths into the #include statements unless you really have to; it causes just this kind of problem.
I agree, but would state it more strongly:
Do not write complete paths into the #include statements ever.
If you do write them, it radically limits the portability of your code. You can't rely on other people's machines having software installed in the same place as it is installed on your system. If you tried it in open source software, you'd be laughed out of court.
Be wary of people who get cute with ../somedir/header.h too — see What are the benefits of a relative path such as "../include/header.h" for a header?.
I observe that the GNU Scientific Library manual has an example program which starts:
#include <stdio.h>
#include <gsl/gsl_sf_bessel.h>
and the section on Compiling and Linking says:
The library header files are installed in their own gsl directory. You should write any preprocessor include statements with a gsl/ directory prefix thus,
#include <gsl/gsl_math.h>
If the directory is not installed on the standard search path of your compiler you will also need to provide its location to the preprocessor as a command line flag. The default location of the gsl directory is /usr/local/include/gsl.
In general it's a bad idea to write paths into the #include statements unless you really have to; it causes just this kind of problem.
On your lab computer, edit R_wrapper.c:
#include <gsl_randist.h>
#include <gsl_rng.h>
The build should now fail. If so then this verifies that you don't have other versions of these headers floating around, or links to them, or whatever. Confirm that it fails, then back out the change, and confirm that it works again.
Then add -I/opt/local/include/gsl to CFLAGS. Verify that the makefile still works.
Then edit R_wrapper.c again; now the build should succeed.
Decide where you would like to keep these files (gsl_randist.h and gsl_rnd.h) on your personal computer, and modify CFLAGS accordingly on your home version of the makefile.
Once all of that is working perfectly, we can show you how to write one makefile that will work on both machines.
Also, you can improve your makefile rules in other ways, but I must ask one question first:
G.o : G.c G.h constants.h utilities.h develop.h
$gcc $(CFLAGS) G.c develop.c
Does G.o really require develop.c? If so then you should probably reexamine your source files, because this is really unhygienic.

GNU-make 4. Running an example for "Loading Dynamic Objects"

The latest version of GNU-Make http://www.gnu.org/software/make/
provides many advanced capabilities, including many useful functions.
(...) On systems which support dynamically loadable objects, you can
write your own extension in any language (which can be compiled into
such an object) and load it to provide extended capabilities... http://www.gnu.org/software/make/manual/make.html#Loading-Objects
I tried to run the simple example below (a $(hello string) function). It works if I first compile the hello.so. But it doesn't work if I run it as the example provided here (with a load directive) http://www.gnu.org/software/make/manual/make.html#Loading-Objects . Make4 is installed in the current directory.
./Makefile:
all:
echo $(hello world)
load hello.so
hello.so: hello.c
$(CC) -shared -I./include -fPIC -o $# $<
./hello.c:
#include <stdlib.h>
#include <stdlib.h>
#include <stdio.h>
#include <string.h>
#include <unistd.h>
#include <errno.h>
#include <gnumake.h>
int plugin_is_GPL_compatible;
char * hello(const char *nm, unsigned int argc, char **argv)
{
int len = strlen (argv[0]) + 7;
char *buf = gmk_alloc (len);
sprintf(buf,"Hello %s",argv[0]);
return buf;
}
int hello_gmk_setup ()
{
gmk_add_function("hello", hello, 1, 1, 1);
return 1;
}
running the example:
./bin/make -v
GNU Make 4.0
Built for i686-pc-linux-gnu
$ ./bin/make
Makefile:4: hello.so: cannot open shared object file: No such file or directory
Makefile:4: *** hello.so: failed to load. Stop.
How can I run this example with the 'load' directive ?
I suggest in a comment to use
-load hello.so
instead of just load hello.so; this is analog to using -include in a Makefile.
The logic is that make plugins are generally expected to exit before you run some make using them (often, you would use a recursive make, e.g. run $(MAKE) -C subdir in a toplevel Makefile and ensure that the plugin does exist when your run $(MAKE) -C subdir)
If hello.so does not exist when -load hello.so is parsed, the GNU make would ignore that directive. (I am not sure you want that for a real plugin).
I still think that make plugins should generally not be built by the Makefile which is load-ing them.
I also believe that using Guile extensions in make is wiser than using plugins.

Resources