There are 4 files:
helper.h //contains the signatures of functions in helper.c
helper.c //implements the signatures in helper.h
file.h //has all the includes needed to run file.h
file.c //this file includes file.h and helper.h
In file.c, I need to use the function that is defined in helper.c in my main function. However, file.c is saying that there is an undefined reference to 'func_found_in_helper.c'
Is this structure correct?
Yes, provided file.c contains
#include "helper.h"
and when building your program you link together helper.o and file.o.
You also need to ensure you compile each of the files with -c so that the compiler only compiles (and not links); do the link later with all the object files.
Here's a working example (I don't actually need a main.h but if you have one of those, #include it from main.c):
main.c
#include <stdio.h>
#include <stdlib.h>
#include "helper.h"
int
main (int argc, char **argv)
{
test ();
exit (0);
}
helper.c
#include <stdio.h>
void
test ()
{
printf ("Hello world\n");
}
helper.h
void test ();
To compile
gcc -Wall -Werror -c -o main.o main.c
gcc -Wall -Werror -c -o helper.o helper.c
To link
gcc -Wall -Werror -o test main.o helper.o
In a Makefile
test: main.o helper.o
gcc -Wall -Werror -o test main.o helper.o
%.o: %.c
gcc -c -Wall -Werror -o $# $<
clean:
rm -f *.o test
To run
$ ./test
Hello world
It's a bit difficult to tell what else might be wrong without the program; my guess is you simply forgot the -c flag to gcc, or forgot to link in helper.o.
undefined reference to 'func_found_in_helper.c'
That's a little odd, as it suggests you have tried to call the function using the '.c' extension, rather than just the function name. Maybe the '.' is just a typo in the question ?
Also a linker will flag an undefined symbol, so it may also be that you have not told the linker where to find helper.o ( the helper.c file compiled to the an object file ). The compiler will start the linker automatically. Did you compile helper.c first ?
Related
I have a problem including my own library.
I have created some functions in a few archives .c,
after that i have created the header file .h,
but when i try to compile a main.c that call a function that was in my own lib
i must to type gcc ownlib.a main.c -o prog.out and include the lib ownlib.a archive
as a parameter of gcc.
In this case i was trying to call my own strlen() called ft_strlen() function that is in my own lib.
I know when i compile any program using a function that is in a compiler library i only must
include the header in the code for example: #include <string.h>,
but when i call my own function i add #include "ownlib.h".
If i compile the main.c calling system function strlen() i have to compile only the main.c
archive and it works.
When i create a lib with my own ft_strlen() and in the main.c i include my own lib
#include "ownlib.h" it doesn´t work if i do this gcc main.c -o program.out
but it works if i add my lib archive like this gcc main.c ownlib.a -o program.out
I want to know why when i use a system library function i don´t need to compile with the library archive,
for example gcc main.c string.c -o program.out,
only whith the #include <string.h> it works,
and why i must to include my ownlib.a in the compiation gcc libft.a main.c -o program.out.
I don't know if I explained myself well
LIBNAME = ownlib.a
HEADERNAME = ownlib.h
SRCS = ft_strlen.c
OBJS = $(SRCS:.c=.o)
CC = gcc
CFLAGS = -Wall -Wextra -Werror
AR = ar
ARFLAGS = -rcs
$(LIBNAME): $(OBJS) $(HEADERNAME)
#$(AR) $(ARFLAGS) $(LIBNAME) $(OBJS)
all: $(LIBNAME)
clean:
$(RM) $(OBJS)
fclean: clean
$(RM) $(LIBNAME)
re: fclean all
%.o: %.c $(HEADERNAME)
#${CC} ${CFLAGS} -c $< -o ${<:.c=.o}
.PHONY: all clean fclean re
one of the functions is like this:
#include "ownlib.h"
size_t ft_strlen(const char *str)
{
int i;
i = 0;
while (str[i] != '\0')
i++;
return (i);
}
Th main function is:
#include <stdio.h>
#include "ownlib.h"
int main(void)
{
char *str;
str = "How many characters";
printf("%i", ft_strlen(str);
return (0);
}
If i compile gcc main.c -o program.out don´t know what is ft_strlen()
Thanks so much
I have a statically linked library, containing a global variable barvar. I can compile the library with no problems with either gcc-10 or clang (this is on macOS Catalina). Interestingly, the behavior differs between the two when I try to link it into a program that uses the library. Here's the code:
In globvars.h, int barvar is declared:
#ifndef H_GLOBVARS_H
#define H_GLOBVARS_H
extern int barvar;
#endif
In globvars.c, int barvar is defined:
#include "globvars.h"
int barvar;
In foo.c, the function foo sets and prints barvar:
#include <stdio.h>
#include "globvars.h"
void foo()
{
barvar = 10;
printf("barvar is: %d\n", barvar);
return;
}
Here's test.c, the program that uses the library:
void foo();
int main(int argc, char **argv)
{
foo();
return 0;
}
When I compile and link with gcc-10, no problems:
gcc-10 -c foo.c -o foo.o
gcc-10 -c globvars.c -o globvars.o
gcc-10 -c test.c -o test.o
gcc-ar-10 rcs liblinktest.a foo.o globvars.o
gcc -o testlinkrun test2.o -L. -llinktest
When I compile and link with clang, I get an undefined symbol error at the last step:
cc -c foo.c -o foo.o
cc -c globvars.c -o globvars.o
cc -c test.c -o test.o
ar rcs liblinktest.a foo.o globvars.o
cc -o testlinkrun test2.o -L. -llinktest
with error:
Undefined symbols for architecture x86_64:
"_barvar", referenced from:
_foo in liblinktest.a(foo.o)
Any ideas? Interestingly, it appears the only step that has to be done with gcc-10 is compiling globvars.c. I can use clang and the clang linker for all other steps, and everything is fine. Is it possible that clang is optimizing away all the variables in globvars.c? How can I prevent this?
As #EricPostpischil observed in this comment, the issue is that clang defaults to treating barvar as a common symbol. Either changing int barvar; to int barvar = 0;, or compiling with -fno-common, fix the issue.
Beginning with gcc-10, gcc's default behavior is -fno-common instead of -fcommon.
I am trying to reorganize someone's code and I seem to have hit a wall.
I have a function int fnc() in fnc.c that is called by either main1.c or main2.c. An executable is compiled from either main1.c or main2.c using a makefile:
main1: main1.o fnc.o
gcc main1.o fnc.o -o main1.x
main2: main2.o fnc.o
gcc main2.o fnc.o -o main2.x
main1.o: main1.c
gcc -c main1.c
main2.o: main2.c
gcc -c main2.c
fnc.o:
gcc -c fnc.c
The only problem is, there are two header files header1.h and header2.h to be included in the preamble of fnc.c depending on whether main1.x or main2.x is compiled:
#include "header1.h"
int fnc(){
// do stuff
}
Is it possible to select which header to be loaded depending on whether one types make main1 or make main2?
You can use the -D compiler flag to define a symbol that will be visible to preprocessor. And then to check it with the preprocessor #ifdef directive. Such as:
Makefile:
main1: main1.o fnc1.o
gcc main1.o fnc1.o -o main1.x
main2: main2.o fnc2.o
gcc main2.o fnc2.o -o main2.x
main1.o: main1.c
gcc -c main1.c
main2.o: main2.c
gcc -c main2.c
fnc1.o:
gcc -o fnc1.o -c fnc.c -DCONFIG1
fnc2.o:
gcc -o fnc2.o -c fnc.c -DCONFIG2
And your source:
#ifdef CONFIG1
#include "header1.h"
#elif defined(CONFIG2)
#include "header2.h"
#else
#error "blah"
#endif
int fnc(){
// do stuff
}
Note - this is neither tested nor an optimal solution. Just giving the idea
According to this question, gcc's -l command requires your library to be named libXXX.a.
Is there a way to link a static library using a different command with gcc? The goal is to avoid this lib- prefix.
Just pass the library as in input file like so:
gcc main.c yourlibrary.a -o prog
Like nunzio said. Just pass it in directly as an input file. He beat me to it, but here's a full example anyway.
mylib.c:
#include <stdio.h>
void say_hi(void)
{
printf("hi\n");
}
main.c:
extern void say_hi(void);
int main(int argc, char**argv)
{
say_hi();
return 0;
}
Makefile:
main: main.c mylib.a
gcc -o main main.c mylib.a
mylib.a: mylib.o
ar rcs mylib.a mylib.o
mylib.o: mylib.c
gcc -c -o $# $^
I realize this assumes some background knowledge in Make. To do the same thing w/o make, run these commands in order:
gcc -c -o mylib.o mylib.c
ar rcs mylib.a mylib.o
gcc -o main main.c mylib.a
I am new to g++ and Makefile. I am trying to link this BeBOP SMC library, which is in my lib directory. Under the lib directory are bebop_util and sparse_matrix_converter, both of which have already been built without errors. I see libbebop_util.a, libbebop_util.so under bebop_util and libsparse_matrix_converter.a, libsparse_matrix_converter.so under sparse_matrix_converter. Below is the source:
Makefile
CC=g++
CFLAGS=-c -Wall
test.out: test.o
$(CC) -o test.out -Ilib/sparse_matrix_converter/include -Llib/bebop_util \
-Llib/sparse_matrix_converter -lbebop_util -lsparse_matrix_converter test.o
test.o: test.cpp
$(CC) $(CFLAGS) -Ilib/sparse_matrix_converter/include test.cpp
clean:
rm -f test.o test.out
test.cpp
#include <bebop/smc/sparse_matrix.h>
#include <bebop/smc/sparse_matrix_ops.h>
int main(int argc, const char* argv[])
{
struct sparse_matrix_t* A = load_sparse_matrix (MATRIX_MARKET, "sample_input");
destroy_sparse_matrix(A);
return 0;
}
Output:
login3% make
g++ -c -Wall -Ilib/sparse_matrix_converter/include test.cpp
g++ -o test.out -Ilib/sparse_matrix_converter/include -Llib/bebop_util -Llib/sparse_matrix_converter -lbebop_util -lsparse_matrix_converter test.o
test.o: In function `main':
test.cpp:(.text+0x1a): undefined reference to `load_sparse_matrix(sparse_matrix_file_format_t, char const*)'
test.cpp:(.text+0x27): undefined reference to `destroy_sparse_matrix(sparse_matrix_t*)'
collect2: ld returned 1 exit status
make: *** [test.out] Error 1
Please note that test.cpp depends on sparse_matrix_converter, which depends on bebop_util. Would you please let me know what mistakes I may have made? Thanks.
Tom
The BeBOP code looks to be C code but hasn't add the correct C++ guards. Surround your includes with extern "C" to fix that:
extern "C" {
#include <bebop/smc/sparse_matrix.h>
#include <bebop/smc/sparse_matrix_ops.h>
}