Im working on a project for stm32f4 to my school. Im using CooCox IDE.
I wanted to add new files "przerwania.c" and "przerwania.h" to write some functions there - not in "main.c". But I have no idea why CooCox is showing me errors.
Earlier I wanted to move some of functions from main.c to pwm.c and them work! But I would like to make a new files couse i have more functions.
Errors in CooCox look like this:
[mkdir] Created dir: D:\CooCox\CoIDE\workspace\testowy2\testowy2\Debug\obj
[cc] 12 total files to be compiled.
[cc] arm-none-eabi-gcc -mcpu=cortex-m4 -mthumb -Wall -ffunction-sections -g -O0 -c -DSTM32F407VG -DSTM32F4XX -DUSE_STDPERIPH_DRIVER -D__ASSEMBLY__ -ID:\CooCox\CoIDE\workspace\testowy2 -ID:\CooCox\CoIDE\workspace\testowy2\cmsis_boot -ID:\CooCox\CoIDE -ID:\CooCox\CoIDE\workspace\testowy2\cmsis_lib\include -ID:\CooCox\CoIDE\workspace\testowy2\cmsis -ID:\CooCox\CoIDE\workspace\testowy2\cmsis_lib -ID:\CooCox\CoIDE\workspace D:\CooCox\CoIDE\workspace\testowy2\cmsis_lib\source\stm32f4xx_syscfg.c D:\CooCox\CoIDE\workspace\testowy2\pwm.c D:\CooCox\CoIDE\workspace\testowy2\dupa.c D:\CooCox\CoIDE\workspace\testowy2\cmsis_boot\startup\startup_stm32f4xx.c D:\CooCox\CoIDE\workspace\testowy2\main.c D:\CooCox\CoIDE\workspace\testowy2\cmsis_lib\source\stm32f4xx_rcc.c D:\CooCox\CoIDE\workspace\testowy2\cmsis_lib\source\stm32f4xx_adc.c D:\CooCox\CoIDE\workspace\testowy2\cmsis_lib\source\stm32f4xx_gpio.c D:\CooCox\CoIDE\workspace\testowy2\cmsis_boot\system_stm32f4xx.c D:\CooCox\CoIDE\workspace\testowy2\cmsis_lib\source\stm32f4xx_exti.c D:\CooCox\CoIDE\workspace\testowy2\cmsis_lib\source\misc.c D:\CooCox\CoIDE\workspace\testowy2\cmsis_lib\source\stm32f4xx_tim.c
[cc] Starting link
[cc] arm-none-eabi-gcc -mcpu=cortex-m4 -mthumb -g -nostartfiles -Wl,-Map=testowy2.map -O0 -Wl,--gc-sections -LD:\CooCox\CoIDE\configuration\ProgramData\testowy2 -Wl,-TD:\CooCox\CoIDE\configuration\ProgramData\testowy2/arm-gcc-link.ld -g -o testowy2.elf ..\obj\stm32f4xx_syscfg.o ..\obj\pwm.o ..\obj\dupa.o ..\obj\startup_stm32f4xx.o ..\obj\main.o ..\obj\stm32f4xx_rcc.o ..\obj\stm32f4xx_adc.o ..\obj\stm32f4xx_gpio.o ..\obj\system_stm32f4xx.o ..\obj\stm32f4xx_exti.o ..\obj\misc.o ..\obj\stm32f4xx_tim.o
[cc] ..\obj\main.o: In function `main':
[cc] D:\CooCox\CoIDE\workspace\testowy2/main.c:336: undefined reference to `Nowafunkcja'
[cc] collect2.exe: error: ld returned 1 exit status
main.c is quite long becouse i have some definitions of few long functions there, so I paste here only a part
#include "stm32f4xx.h"
#include "misc.h"
#include "stm32f4xx_syscfg.h"
#include "stm32f4xx_adc.h"
#include "stm32f4xx_exti.h"
#include "przerwania.h"//here is the problem
#include "pwm.h"
int main(void)
{
SystemInit();
//IniDiody();
//TimConfig();
//NVIC_Config();
//IniDiodyPWM();
LEDInit();
EXTILine0_Config();
PWM2();//wiwo
GPIO();//wiwo
Nowafunkcja();//PROBLEM
RCC_Konfiguracja_Adc12();
GPIO_Configuration_Adc1();
ADC1_Configuration();
GPIO_Configuration_Adc1();
GPIO_Configuration_Adc2();
ADC2_Configuration();
IniDiody(GPIO_Pin_14);
IniTimerPrzerwanie1();
while(1)
{
ADC_SoftwareStartConv(ADC1);
ADC_SoftwareStartConv(ADC2);
while(ADC_GetFlagStatus(ADC1, ADC_FLAG_EOC) == RESET);
wynikADC1 = (float)ADC_GetConversionValue(ADC1);
while(ADC_GetFlagStatus(ADC2, ADC_FLAG_EOC) == RESET);
wynikADC2 = (float)ADC_GetConversionValue(ADC2);
wartosc = (int)(wynikADC2 * 15);
//doPWM=(((float)ADCResult) / 41);
//wartosc = (int) doPWM;
//TIM2->CCR3 = (int) doPWM;
TIM3->CCR2 = 65535;
TIM3->CCR1 = wartosc;//(int)(wynikADC2 * 15);
wartoscPrescalera=(int)SystemCoreClock;
}
}
and files:
przerwania.h
#ifndef __przerwaniah
#define __przerwaniah
void Nowafunkcja(void);
#endif
przerwania.c
#include "przerwania.h"
void Nowafunkcja(void)
{
//nothing here - just for test
}
Do you have any idea what is the problem? I'm thinking about this since yesterday and its wird :/
I'll appreciate your help!
Take a look at the line under [cc] 12 total files to be compiled.
When you added pwm.c, you also informed the compiler to include this file. You'll see it listed there. przerwania.c is not.
If you add przerwania the same way you added pwm, your IDE will take care of making sure it is included in the build.
I'm not sure what your current file/folder structure looks like:
http://www.coocox.org/CoIDE/Project_management_config.html can help you determine how to pull those new files into the build.
FWIW:
The (anthropomorphized) compiler step says: Is this valid code? So it looks though your main.c, sees that you included przerwania.h, and comes to the conclusion that you correctly used the Nowafunkcja function (just matched the signature). Even though at this point, it has NOT looked into przerwania.c to find out what it does. The compiler goes on to do this for all of your files and keeps track of what functions are defined in each file. Note that it never found the definition Nowafunkcja, because the compiler never compiled przerwania.c. It did however find the declaration in the .h (because main.c told it exactly where to find the .h)
The linker then gets this stuff from the compiler, including what functions have been defined in all your .c files. That's the first point where something tries to answer the question "Now what code do I actually need to run when he asked me to Nowafunkcja()?". So that's the first point in the build when the tools realized, I never found code for Nowafunkcja in any of the .c files I was looking in.
So, I think that roughly answers "Why", but we need to know more about your project organization to give you a "fix" to make it work.
Related
Just a simple program, but I keep getting this compiler error. I'm using MinGW for the compiler.
Here's the header file, point.h:
//type for a Cartesian point
typedef struct {
double x;
double y;
} Point;
Point create(double x, double y);
Point midpoint(Point p, Point q);
And here's point.c:
//This is the implementation of the point type
#include "point.h"
int main() {
return 0;
}
Point create(double x, double y) {
Point p;
p.x = x;
p.y = y;
return p;
}
Point midpoint(Point p, Point q) {
Point mid;
mid.x = (p.x + q.x) / 2;
mid.y = (p.y + q.y) / 2;
return mid;
}
And here's where the compiler issue comes in. I keep getting:
testpoint.c: undefined reference to 'create(double x, double y)'
While it is defined in point.c.
This is a separate file called testpoint.c:
#include "point.h"
#include <assert.h>
#include <stdio.h>
int main() {
double x = 1;
double y = 1;
Point p = create(x, y);
assert(p.x == 1);
return 0;
}
I'm at a loss as to what the issue could be.
How are you doing the compiling and linking? You'll need to specify both files, something like:
gcc testpoint.c point.c
...so that it knows to link the functions from both together. With the code as it's written right now, however, you'll then run into the opposite problem: multiple definitions of main. You'll need/want to eliminate one (undoubtedly the one in point.c).
In a larger program, you typically compile and link separately to avoid re-compiling anything that hasn't changed. You normally specify what needs to be done via a makefile, and use make to do the work. In this case you'd have something like this:
OBJS=testpoint.o point.o
testpoint.exe: $(OBJS)
gcc $(OJBS)
The first is just a macro for the names of the object files. You get it expanded with $(OBJS). The second is a rule to tell make 1) that the executable depends on the object files, and 2) telling it how to create the executable when/if it's out of date compared to an object file.
Most versions of make (including the one in MinGW I'm pretty sure) have a built-in "implicit rule" to tell them how to create an object file from a C source file. It normally looks roughly like this:
.c.o:
$(CC) -c $(CFLAGS) $<
This assumes the name of the C compiler is in a macro named CC (implicitly defined like CC=gcc) and allows you to specify any flags you care about in a macro named CFLAGS (e.g., CFLAGS=-O3 to turn on optimization) and $< is a special macro that expands to the name of the source file.
You typically store this in a file named Makefile, and to build your program, you just type make at the command line. It implicitly looks for a file named Makefile, and runs whatever rules it contains.
The good point of this is that make automatically looks at the timestamps on the files, so it will only re-compile the files that have changed since the last time you compiled them (i.e., files where the ".c" file has a more recent time-stamp than the matching ".o" file).
Also note that 1) there are lots of variations in how to use make when it comes to large projects, and 2) there are also lots of alternatives to make. I've only hit on the bare minimum of high points here.
I had this issue recently. In my case, I had my IDE set to choose which compiler (C or C++) to use on each file according to its extension, and I was trying to call a C function (i.e. from a .c file) from C++ code.
The .h file for the C function wasn't wrapped in this sort of guard:
#ifdef __cplusplus
extern "C" {
#endif
// all of your legacy C code here
#ifdef __cplusplus
}
#endif
I could've added that, but I didn't want to modify it, so I just included it in my C++ file like so:
extern "C" {
#include "legacy_C_header.h"
}
(Hat tip to UncaAlby for his clear explanation of the effect of extern "C".)
I think the problem is that when you're trying to compile testpoint.c, it includes point.h but it doesn't know about point.c. Since point.c has the definition for create, not having point.c will cause the compilation to fail.
I'm not familiar with MinGW, but you need to tell the compiler to look for point.c. For example with gcc you might do this:
gcc point.c testpoint.c
As others have pointed out, you also need to remove one of your main functions, since you can only have one.
Add the "extern" keyword to the function definitions in point.h
I saw here that this question
In c programming language, i keep getting this error
has been answered here so the thread seems closed for answers.
I disagree. It is different code.
The answer should be that we don't know what is in custom header file "functions.h".
Also, we don't know what are
MAPA m;
POSICAO heroi;
Are these functions, constants?
If these were some constants, one should expect #define in front of them, and no semicolon e.g.
#define MAPA m
#define POSICAO heroi
If You intended to prototype the function, since there's is semicolon behing, than You did not insert the parentheses ().
In that case MAPA and POSICAO are some custom-type functions, whose content should be determined in "Functions.h"
Also, there's a possibilty that You wanted to import the functions or variable or constant from some other directory, and in that case You're missing the word
extern MAPA m;
I had a similar problem running a bunch of .c files in a directory all linking to one header file with custom function prototypes.
I ran:
$gcc -Wall -Werror -Wextra -pedantic -std=gnu89 *.c
Getting these errors:
/usr/bin/ld: /tmp/ccovH4zH.o: in function `_puts': 3-puts.c:(.text+0x2f): undefined reference to `_putchar'
/usr/bin/ld: 3-puts.c:(.text+0x51): undefined reference to `_putchar'
/usr/bin/ld: /tmp/ccGeWRqI.o: in function `main': _putchar.c:(.text+0xe): undefined reference to `_putchar'
/usr/bin/ld: _putchar.c:(.text+0x18): undefined reference to `_putchar'
/usr/bin/ld: _putchar.c:(.text+0x22): undefined reference to `_putchar'
/usr/bin/ld: /tmp/ccGeWRqI.o:_putchar.c:(.text+0x2c): more undefined references to `_putchar' follow
collect2: error: ld returned 1 exit status
Note: All files were linked to the same header file with all the function declarations.
I manage to compile successfully after adding -c option to the gcc compiler like:
$gcc -Wall -Werror -Wextra -pedantic -std=gnu89 -c *.c
This run successfully.
Just in case anyone comes across the same.
Just a simple program, but I keep getting this compiler error. I'm using MinGW for the compiler.
Here's the header file, point.h:
//type for a Cartesian point
typedef struct {
double x;
double y;
} Point;
Point create(double x, double y);
Point midpoint(Point p, Point q);
And here's point.c:
//This is the implementation of the point type
#include "point.h"
int main() {
return 0;
}
Point create(double x, double y) {
Point p;
p.x = x;
p.y = y;
return p;
}
Point midpoint(Point p, Point q) {
Point mid;
mid.x = (p.x + q.x) / 2;
mid.y = (p.y + q.y) / 2;
return mid;
}
And here's where the compiler issue comes in. I keep getting:
testpoint.c: undefined reference to 'create(double x, double y)'
While it is defined in point.c.
This is a separate file called testpoint.c:
#include "point.h"
#include <assert.h>
#include <stdio.h>
int main() {
double x = 1;
double y = 1;
Point p = create(x, y);
assert(p.x == 1);
return 0;
}
I'm at a loss as to what the issue could be.
How are you doing the compiling and linking? You'll need to specify both files, something like:
gcc testpoint.c point.c
...so that it knows to link the functions from both together. With the code as it's written right now, however, you'll then run into the opposite problem: multiple definitions of main. You'll need/want to eliminate one (undoubtedly the one in point.c).
In a larger program, you typically compile and link separately to avoid re-compiling anything that hasn't changed. You normally specify what needs to be done via a makefile, and use make to do the work. In this case you'd have something like this:
OBJS=testpoint.o point.o
testpoint.exe: $(OBJS)
gcc $(OJBS)
The first is just a macro for the names of the object files. You get it expanded with $(OBJS). The second is a rule to tell make 1) that the executable depends on the object files, and 2) telling it how to create the executable when/if it's out of date compared to an object file.
Most versions of make (including the one in MinGW I'm pretty sure) have a built-in "implicit rule" to tell them how to create an object file from a C source file. It normally looks roughly like this:
.c.o:
$(CC) -c $(CFLAGS) $<
This assumes the name of the C compiler is in a macro named CC (implicitly defined like CC=gcc) and allows you to specify any flags you care about in a macro named CFLAGS (e.g., CFLAGS=-O3 to turn on optimization) and $< is a special macro that expands to the name of the source file.
You typically store this in a file named Makefile, and to build your program, you just type make at the command line. It implicitly looks for a file named Makefile, and runs whatever rules it contains.
The good point of this is that make automatically looks at the timestamps on the files, so it will only re-compile the files that have changed since the last time you compiled them (i.e., files where the ".c" file has a more recent time-stamp than the matching ".o" file).
Also note that 1) there are lots of variations in how to use make when it comes to large projects, and 2) there are also lots of alternatives to make. I've only hit on the bare minimum of high points here.
I had this issue recently. In my case, I had my IDE set to choose which compiler (C or C++) to use on each file according to its extension, and I was trying to call a C function (i.e. from a .c file) from C++ code.
The .h file for the C function wasn't wrapped in this sort of guard:
#ifdef __cplusplus
extern "C" {
#endif
// all of your legacy C code here
#ifdef __cplusplus
}
#endif
I could've added that, but I didn't want to modify it, so I just included it in my C++ file like so:
extern "C" {
#include "legacy_C_header.h"
}
(Hat tip to UncaAlby for his clear explanation of the effect of extern "C".)
I think the problem is that when you're trying to compile testpoint.c, it includes point.h but it doesn't know about point.c. Since point.c has the definition for create, not having point.c will cause the compilation to fail.
I'm not familiar with MinGW, but you need to tell the compiler to look for point.c. For example with gcc you might do this:
gcc point.c testpoint.c
As others have pointed out, you also need to remove one of your main functions, since you can only have one.
Add the "extern" keyword to the function definitions in point.h
I saw here that this question
In c programming language, i keep getting this error
has been answered here so the thread seems closed for answers.
I disagree. It is different code.
The answer should be that we don't know what is in custom header file "functions.h".
Also, we don't know what are
MAPA m;
POSICAO heroi;
Are these functions, constants?
If these were some constants, one should expect #define in front of them, and no semicolon e.g.
#define MAPA m
#define POSICAO heroi
If You intended to prototype the function, since there's is semicolon behing, than You did not insert the parentheses ().
In that case MAPA and POSICAO are some custom-type functions, whose content should be determined in "Functions.h"
Also, there's a possibilty that You wanted to import the functions or variable or constant from some other directory, and in that case You're missing the word
extern MAPA m;
I had a similar problem running a bunch of .c files in a directory all linking to one header file with custom function prototypes.
I ran:
$gcc -Wall -Werror -Wextra -pedantic -std=gnu89 *.c
Getting these errors:
/usr/bin/ld: /tmp/ccovH4zH.o: in function `_puts': 3-puts.c:(.text+0x2f): undefined reference to `_putchar'
/usr/bin/ld: 3-puts.c:(.text+0x51): undefined reference to `_putchar'
/usr/bin/ld: /tmp/ccGeWRqI.o: in function `main': _putchar.c:(.text+0xe): undefined reference to `_putchar'
/usr/bin/ld: _putchar.c:(.text+0x18): undefined reference to `_putchar'
/usr/bin/ld: _putchar.c:(.text+0x22): undefined reference to `_putchar'
/usr/bin/ld: /tmp/ccGeWRqI.o:_putchar.c:(.text+0x2c): more undefined references to `_putchar' follow
collect2: error: ld returned 1 exit status
Note: All files were linked to the same header file with all the function declarations.
I manage to compile successfully after adding -c option to the gcc compiler like:
$gcc -Wall -Werror -Wextra -pedantic -std=gnu89 -c *.c
This run successfully.
Just in case anyone comes across the same.
I have 2 c files (& their header files). I have included the function "put" in the corresponding header, but I still have the following errors, when I input "gcc -o main main.c" in the terminal.
main.c:(.text+0x389): undefined reference to `put' collect2: error: ld
returned 1 exit status
may I know the reason? How should I modify my code?
I tried to change the linking order in makefile but failed. Any advice is appreciated, thanks!
CMakeLists.txt
cmake_minimum_required(VERSION 3.19)
project(Demo)
set(CMAKE_CXX_STANDARD 14)
include_directories(.)
add_executable(Demo
main.c main.h KeyValueStore.c KeyValueStore.h )
main.c
#include "main.h"
...
int main() {
...
if (strcmp("PUT", tokens[0]) == 0) {
put(tokens[1], tokens[2]);
...
}
main.h
...
#include "KeyValueStore.h"
...
KeyValueStore.c
#include "KeyValueStore.h"
#define BUFSIZE 1024
typedef struct KeyValueStore {
char key[BUFSIZE];
char value[BUFSIZE];
} KV_Store;
KV_Store kvStore[BUFSIZE];
...
int put(char* key, char* value){
...
}
KeyValueStore.h
...
typedef struct KeyValueStore;
int put(char* key, char* value);
...
Check to see if you have any .o files in that folder and delete them if you do. It's possible the compiler failed at some point while compiling which left *.o files that aren't linked properly
EDIT: I misread the question because for some reason it came up as a c++17 question for me. I'm not sure if what I said still applies to C though I do know it works with C++. Sorry about that to everyone that read my answer before I edited it
Not 100% sure if this is why you are having the error, though you need to put all .c files in the compiler.
So you currently are trying to "gcc -o main main.c" where instead you want to do something more like "gcc -o main main.c keyValueStore.c".
If you do not give the compiler every .c file, it won't have all the definitions and you will get an error similar to what you have.
I also don't really think you need main.h, assuming there isn't any more code in there, it really isn't worth having a whole extra file and instead just putting the #include in main.c.
Just a simple program, but I keep getting this compiler error. I'm using MinGW for the compiler.
Here's the header file, point.h:
//type for a Cartesian point
typedef struct {
double x;
double y;
} Point;
Point create(double x, double y);
Point midpoint(Point p, Point q);
And here's point.c:
//This is the implementation of the point type
#include "point.h"
int main() {
return 0;
}
Point create(double x, double y) {
Point p;
p.x = x;
p.y = y;
return p;
}
Point midpoint(Point p, Point q) {
Point mid;
mid.x = (p.x + q.x) / 2;
mid.y = (p.y + q.y) / 2;
return mid;
}
And here's where the compiler issue comes in. I keep getting:
testpoint.c: undefined reference to 'create(double x, double y)'
While it is defined in point.c.
This is a separate file called testpoint.c:
#include "point.h"
#include <assert.h>
#include <stdio.h>
int main() {
double x = 1;
double y = 1;
Point p = create(x, y);
assert(p.x == 1);
return 0;
}
I'm at a loss as to what the issue could be.
How are you doing the compiling and linking? You'll need to specify both files, something like:
gcc testpoint.c point.c
...so that it knows to link the functions from both together. With the code as it's written right now, however, you'll then run into the opposite problem: multiple definitions of main. You'll need/want to eliminate one (undoubtedly the one in point.c).
In a larger program, you typically compile and link separately to avoid re-compiling anything that hasn't changed. You normally specify what needs to be done via a makefile, and use make to do the work. In this case you'd have something like this:
OBJS=testpoint.o point.o
testpoint.exe: $(OBJS)
gcc $(OJBS)
The first is just a macro for the names of the object files. You get it expanded with $(OBJS). The second is a rule to tell make 1) that the executable depends on the object files, and 2) telling it how to create the executable when/if it's out of date compared to an object file.
Most versions of make (including the one in MinGW I'm pretty sure) have a built-in "implicit rule" to tell them how to create an object file from a C source file. It normally looks roughly like this:
.c.o:
$(CC) -c $(CFLAGS) $<
This assumes the name of the C compiler is in a macro named CC (implicitly defined like CC=gcc) and allows you to specify any flags you care about in a macro named CFLAGS (e.g., CFLAGS=-O3 to turn on optimization) and $< is a special macro that expands to the name of the source file.
You typically store this in a file named Makefile, and to build your program, you just type make at the command line. It implicitly looks for a file named Makefile, and runs whatever rules it contains.
The good point of this is that make automatically looks at the timestamps on the files, so it will only re-compile the files that have changed since the last time you compiled them (i.e., files where the ".c" file has a more recent time-stamp than the matching ".o" file).
Also note that 1) there are lots of variations in how to use make when it comes to large projects, and 2) there are also lots of alternatives to make. I've only hit on the bare minimum of high points here.
I had this issue recently. In my case, I had my IDE set to choose which compiler (C or C++) to use on each file according to its extension, and I was trying to call a C function (i.e. from a .c file) from C++ code.
The .h file for the C function wasn't wrapped in this sort of guard:
#ifdef __cplusplus
extern "C" {
#endif
// all of your legacy C code here
#ifdef __cplusplus
}
#endif
I could've added that, but I didn't want to modify it, so I just included it in my C++ file like so:
extern "C" {
#include "legacy_C_header.h"
}
(Hat tip to UncaAlby for his clear explanation of the effect of extern "C".)
I think the problem is that when you're trying to compile testpoint.c, it includes point.h but it doesn't know about point.c. Since point.c has the definition for create, not having point.c will cause the compilation to fail.
I'm not familiar with MinGW, but you need to tell the compiler to look for point.c. For example with gcc you might do this:
gcc point.c testpoint.c
As others have pointed out, you also need to remove one of your main functions, since you can only have one.
Add the "extern" keyword to the function definitions in point.h
I saw here that this question
In c programming language, i keep getting this error
has been answered here so the thread seems closed for answers.
I disagree. It is different code.
The answer should be that we don't know what is in custom header file "functions.h".
Also, we don't know what are
MAPA m;
POSICAO heroi;
Are these functions, constants?
If these were some constants, one should expect #define in front of them, and no semicolon e.g.
#define MAPA m
#define POSICAO heroi
If You intended to prototype the function, since there's is semicolon behing, than You did not insert the parentheses ().
In that case MAPA and POSICAO are some custom-type functions, whose content should be determined in "Functions.h"
Also, there's a possibilty that You wanted to import the functions or variable or constant from some other directory, and in that case You're missing the word
extern MAPA m;
I had a similar problem running a bunch of .c files in a directory all linking to one header file with custom function prototypes.
I ran:
$gcc -Wall -Werror -Wextra -pedantic -std=gnu89 *.c
Getting these errors:
/usr/bin/ld: /tmp/ccovH4zH.o: in function `_puts': 3-puts.c:(.text+0x2f): undefined reference to `_putchar'
/usr/bin/ld: 3-puts.c:(.text+0x51): undefined reference to `_putchar'
/usr/bin/ld: /tmp/ccGeWRqI.o: in function `main': _putchar.c:(.text+0xe): undefined reference to `_putchar'
/usr/bin/ld: _putchar.c:(.text+0x18): undefined reference to `_putchar'
/usr/bin/ld: _putchar.c:(.text+0x22): undefined reference to `_putchar'
/usr/bin/ld: /tmp/ccGeWRqI.o:_putchar.c:(.text+0x2c): more undefined references to `_putchar' follow
collect2: error: ld returned 1 exit status
Note: All files were linked to the same header file with all the function declarations.
I manage to compile successfully after adding -c option to the gcc compiler like:
$gcc -Wall -Werror -Wextra -pedantic -std=gnu89 -c *.c
This run successfully.
Just in case anyone comes across the same.
I have a project that I recently split up into headers + sources, and now clang-tidy wont "actually" check my test files that include these headers. Below is an example of the situation:
File Structure:
src/
main.c
a.h
a.c
test/
test.c
Code:
// src/main.c
#include "src/a.h"
int main(void) {
a();
return 0;
}
// src/a.h
void a(void);
// src/a.c
#include <stdlib.h>
#include "src/a.h"
void a(void) {
malloc(1); // obvious memory leak
}
// test/test.c
#include "src/a.h"
int main(void) {
// do test stuff
a();
return 0;
}
Compile src: cc src/*.c -I. -o main
Compile test: cc src/a.c test/test.c -I. -o test
Running does nothing, but the code does compile.
Then, I run the code through clang-tidy:
clang-tidy src/* -- -I.
This works:
1 warning generated.
1 warning generated.
1 warning generated.
/src/a.c:8:1: warning: Potential memory leak [clang-analyzer-unix.Malloc]
}
^
/src/a.c:7:2: note: Memory is allocated
malloc(1);
^
/src/a.c:8:1: note: Potential memory leak
}
^
But if I do:
clang-tidy test/test.c -- -I.
Nothing is outputed (ive tried to add the header-filter flag as well).
I pressume that the headers are being included, and the test code has no knowledge of the source. So, how can I make sure my tests are actually being checked if this is the case? These headers and sources are in my project, so it would only make sense that clang-tidy would be able to pick up on this?
Edit:
I can do the following, and it seems to only partially fix the problem:
// test/test.c
#include "src/a.h"
#include "src/a.c" //added this line
int main(void) {
// do test stuff
a();
return 0;
}
Now, clang-tidy picks up on the actual .c file, and thus finds the issue. But, now I cant compile my code. There is supposed to be a __clang_analyzer__ define that gets set when the code is being analyzed, but it seems to just ignore it:
#ifdef __clang_analyzer__
#include "src/a.c" // doesnt include file, thus the malloc() call is never detected
#endif
clang-tidy is only a static analyser tool, said differently a linter. It does not try to build or run an executable: it just analyses the C source files it has been given after processing the include parts.
Static analysis and testing are different parts of a quality assurance process:
the former only reads source files searching for common errors and runs nothing
the latter runs (parts of) a code base with known inputs and controls that outputs have expected values
That means that clang-tidy is expected to be run on your main sources, not only on the test ones.
To be clear, it can make sense to pass test sources to the linter, because they could contain problems that clang-tidy would detect. But only running clang-tidy on the test folder will not detect problem in main folder, whatever the coverage.