I'm trying to run make on an Ubuntu machine to compile a RoT MUD, but the farthest I've gotten is when I get a collect2: error: ld returned 1 exit status.
This is what comes immediately before the error in the terminal (along with a lot of other similar errors):
/usr/bin/ld: obj/wizlist.o:/home/lucas/Projects/R2b5/src/merc.h:3355: multiple definition of `bllmax'; obj/act_comm.o:/home/lucas/Projects/R2b5/src/merc.h:3355: first defined here
From what I've gathered this means that the header files have variable declarations in them, and that using static is an easy fix, however, I haven't been able to figure out where I should put that keyword in the code to fix this issue. The following is the only mention of bllmax in merc.h:
int bllmax, crbmax, crnmax, srpmax, mngmax;
Here is the program I'm trying to compile.
You need to learn the difference between declaration and definition. A declaration is telling the compiler that the symbol exists somewhere but possibly not here. A definition is telling the compiler that the symbol exists here.
The line you show (without any context) is defining the variables, which means they will be defined in each source file that includes the header file.
What it should do is to declare the variables, which can be done by making them extern:
extern int bllmax, crbmax, crnmax, srpmax, mngmax;
Then in a single source file define the variables (without extern).
Related
Why does the compiler sometimes not give line number of the error? Where is the use case of that "undefined reference". I've already included everything as header files I myself wrote so it needs to give a specific line number. It is not closed source. Have I changed some setting of the compiler by accident or is it another thing whatever that another thing is?
D:\Projects\DanceOfPixels\GLEW>gcc main.c glad.c -IC:\mingw_dev_lib\include\SDL2 -LC:\mingw_dev_lib\lib -lmingw32 -lopengl32 -lSDL2main -lSDL2 -lSDL2_image -o main.exe -ansi -std=c89 -pedantic -w
C:\Users\user\AppData\Local\Temp\ccMooHZm.o:main.c:(.text+0x126ce): undefined reference to `drawImagePartScaledHW'
collect2.exe: error: ld returned 1 exit status
Edit: I have solved the problem. I have included two different versions of the draw.h, one coming from software renderer, other from OpenGL renderer. Since they use same
#ifndef DRAW_H
#define DRAW_H
...
#endif
structure for both files; the compiler didn't include the second. Once I've changed the DRAW_H to DRAW_HW I managed to compile and run the application.
That error comes from the "linker" (ld), not the compiler proper.
Typically, the compiler compiles each source file into its own, individual object file, containing just the code and data from that source file. Then, the linker combines one or more object files together, and also links in any needed library functions.
Crucially, there's no problem if a single source file (a single object file) calls an undefined function -- that's normal, if the definition of the function is in another source file, or a library. So that's why it's the linker (not the compiler) that finally discovers that there's not a definition for a function anywhere, that it's truly undefined.
But since the linker is working with object files, typically it doesn't know which source file line numbers the functions were originally called on.
(Some C compilers work more closely with their linkers, so that these "undefined external" error messages can, more usefully, contain actual source file line numbers, but that's a relatively recent innovation. For this to work it may be important to compile with debugging enabled, e.g. by using the -g flag, so that the compiler includes source line number information in its object files.)
anyone can help me?? my board is LPC1768 and the sensor is BMP180
Rebuild target 'Target 1'
compiling BMP180.c...
compiling I2C.c...
assembling startup_LPC17xx.s...
compiling system_LPC17xx.c...
compiling GPIO_LPC17xx.c...
compiling PIN_LPC17xx.c...
linking...
.\Objects\asdsa.axf: Error: L6218E: Undefined symbol main (referred from __rtentry2.o).
Not enough information to list image symbols.
Finished: 1 information, 0 warning and 1 error messages.
".\Objects\asdsa.axf" - 1 Error(s), 0 Warning(s).
Target not created.
I found the solution is easy, but before going deeper into the solution, keep in mind that C compilation unit (C Compiler and Assembler at least) compiles each pure C source file after resolving necessary pre-processor directives, and generates a relocatable object file as a result of compilation.
After the compilation unit does its job, there is another unit that is responsible for combining individually every source file that is compiled successfully into the relocatable form of one big object file for all. This unit is called Linker and the operation is called Linking
A very important feature in relocatable object file is that what is called variable, function will be noted as symbol so far. The linker has to solve the symbols, defining what is originally defined in an object file, reference what is being used in another to their original object file.
After this motivation, now we can call main() function as main() symbol.
I Found that the problem is because the source file that contains the main() function was not compiled. As a result, there is no a relocatable object file that contains the symbol corresponding to main() function. Hence, the compiler is complaining: you asked me to use (reference) a symbol you guaranteed to be found (defined) in another file but I found no such symbol!
The solution:
For Kiel IDE, to queue a source file for a compilation; you gotta shortlist it in the category "Source Group",by clicking right, either adding new files to group, or existing files to group. It will result in something like the following figure:
Now we have a main function, is turned (defined) to main symbol later, and found by the linker to reference it to whatever use it in any other relocatable object files.
I solved this problem with the following steps;
Delete your old project and create new project
Choose true library from Manage Run Time Environment like so:
Configure "Options for Target" segment. Define symbol USE_STDPERIPH_DRIVER and define project path like so:
Test your configuration. Please write the following code:
#include "stm32f10x.h" // Device header
int main() {
}
I had the same issue. The problem was that the function name in .c file had a different name with the one in the .h file, and I didn't know.
just add your c file (ex: 'main.c') to the source group (ex: 'source group 1') by expanding the target then right click on the source group, choose add existing files to group 'your source group', then choose the main.c file.
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.faqs/14222.html
This should help.
Just create a dummy main() or main.c file. Linker can't find it in your pjt.
For solution only add this file C to driver folder and translate it,
Solved: This "Target Not Created" Issue was Resolved by the setting of Run Time Environment as shown in below(url) image.https://i.stack.imgur.com/kJ4IL.jpg ( consisting of CMSIS and Device supporting components in Run time environment)
{ compiling TransformFunctions.c...
linking...
Program Size: Code=768 RO-data=320 RW-data=4 ZI-data=612
FromELF: creating hex file...
".\Objects\LPC1768_B_T.axf" - 0 Error(s), 0 Warning(s).
Build Time Elapsed: 00:00:07
}
I am trying to create a makefile and was able to get all of the files to compile but it fails on the linker step. Every function in the project is getting an error where it says GCC multiple definition of 'Function Name' then claims that it was first defined in the exact same spot. For example...
project/src/provCreator.o: In function `ProcessArgs':
/home/kevin/project/src/provCreator.c:380: multiple definition of `ProcessArgs'
project/src/provCreator.o:/home/kevin/project/src/provCreator.c:380: first defined here
What are possible causes of this error and how can it be fixed?
Thank you for helping.
Your makefile has project/src/provCreator.c file listed twice. Possibly, with different relative paths.
From your description, it seems that all c files are listed twice (ctrl-c/ctrl-v error?)
Any linker throws a multiple definition error while functions with the same name compiled or same function compiled multiple times due to duplicate listings in makefile. After compilation, while linking linker will be in confusion which object definition it has to link hence it throws an error.
In your case, please check your makefile, probably you might have listed provCreator.c twice.
I had a function in a file "draw.h":
void TileSystem() {
// Some code here.
}
And in the "main.c" file, I call it, because I have #included "draw.h" in the file. The function works nicely well!!
But then, I decide to rename the function to
void CreateTileSystem() {
// Some code here.
}
And I get the following output:
gcc main.c -std=c99 -o main `pkg-config --cflags --libs allegro-5.0 allegro_acodec-5.0 allegro_audio-5.0 allegro_color-5.0 allegro_dialog-5.0 allegro_font-5.0 allegro_image-5.0 allegro_main-5.0 allegro_memfile-5.0 allegro_physfs-5.0 allegro_primitives-5.0 allegro_ttf-5.0`
main.c: In function ‘main’:
main.c:217:12: warning: implicit declaration of function ‘CreateTileSystem’ [-Wimplicit-function-declaration]
/tmp/cclNEg6q.o: In function `main':
main.c:(.text+0xb1e): undefined reference to `CreateTileSystem'
collect2: error: ld returned 1 exit status
make: *** [main] Error 1
And then, I just rename it back to TileSystem and works well. I have no other references in the entire code. It makes no sense at all! I want to rename, in order to use verbs in functions (A more "correct" standard, I think). Well, I would really like to know what happens. I really CAN'T find errors, and the fact that when I rename it, it backs to work, frustrates me even more.
Thank you very much!
You have to also change the name in the header file, draw.h.
That error/warning indicates that there was no forward declaration for the function, which in older C dialects results in an assumption that the function is int fn(int) (if memory serves).
It works when you change it back because the header was never modified, so it's still providing a forward declaration of the old name.
I tried creating a couple of simple files like you've described here, but I don't get any problems. So:
are you sure you used the same name for the new function in both draw.h and main.c (really sure)?
I don't know about allegro: does it happen to have a function called TileSystem in it?
Beyond those, I would recommend starting with a bare bones setup (so just the include, the main function, and the call in main.c, and just the declaration in draw.h), make sure that compiles with gcc main.c -std=c99 -o main, and then build your application up to what it is currently, piece by piece, until the error starts happening again. That should help you identify the source of the problem.
I recreated the header file, without altering anything, and it worked. It really had something to do with me never altering the file (I mean, renaming the file or excluding it). Some very underground compiling issue happened.
I'm using CppUTest to test the C code defined in a fornol.c source file. That file defines the main production main() function.
I also have an AllTests.cpp file that also has a main() function, but that main() is supposed to be used only when running the unit tests.
AllTests.cpp gets compiled to a .o file, whereas fornol.c gets compiled to a libfornol.a archive.
Then CppUTest tries to link everything together, but here is what I get instead:
Linking fornol_tests
cc -o fornol_tests objs/tests/AllTests.o objs/tests/FornolTests.o lib/libfornol.a ../../CppUTest/lib/libCppUTest.a ../../CppUTest/lib/libCppUTestExt.a -lstdc++ -lgcov
lib/libfornol.a(fornol.o): In function `main':
/home/dlindelof/Work/endor/nol/fornol/fornol.c:453: multiple definition of `main'
objs/tests/AllTests.o:/home/dlindelof/Work/endor/nol/fornol/tests/AllTests.cpp:4: first defined here
collect2: ld returned 1 exit status
It looks as if the main() function defined in fornol.c and present in the archive libfornol.a conflicts with the main() defined in AllTests.cpp. But my understanding was that archive/library files are searched only if/when a given symbol hasn't been referenced yet. It should therefore not be a problem to have the same symbol defined more than once, provided all definitions are in archive/library files.
What am I doing wrong here?
You need to remove the main() from AllTests.cpp and put it in its own source file.
When a linker links in a library, it can't split object files in the library; it has to either link or omit each object file in the library as a unit. (I know LLVM is different, but that's another topic.) This is why, if you look at the source for a library like glibc, each function gets its own source file.
So what's happening to you is that the linker needs to pull in an object file (fornol.o) from the library (libfornol.a) to satisfy dependencies, but that object file carries a duplicate symbol with it (main).
It's perfectly okay to put test code in a library (we do this routinely where I work), but keep it in its own source files (we traditionally use main.cc). (This is a better test anyway, because test code should not have access to static-declared symbols.)
A library is supposed not to have a main() function as it is a library.
You should remove that main() from fornol.c and compile it again.
main() is the entry point of an executable file's source code, since a library (especially a static ".a" library) is only pre-compiled source code, you cannot use a main in there.
If you want a main production entry point of your library you could rename the main() in fornol.c to something more explicit and less reserved such as "fornolMain()" for example.
A static library is compiled in your binary executable and thus is not searched only if the symbol is loaded. It is exactly the same as compiling fornol.c and linking fornol.o and your other .o