I've got an update function in my game that contains the following code:
void DrawMiniFPSCounter();
DrawMiniFPSCounter();
The DrawMiniFPSCounter() function is declared in a file called miniFPSCounter.cpp, which is part of the build target (I'm using Xcode). When building, I get a linker error saying that the DrawMiniFPSCounter symbol cannot be found. I've tried removing the declaration above and just calling DrawMiniFPSCounter() but that results in a 'symbol not found' error during compilation. Why would the linker have trouble finding this symbol? Is it something to do with the order in which symbols are resolved in the project?
EDIT: I ran the command nm hrMiniFPSCounter.o | grep Draw in my build directory, and got the following output:
00000000 T __Z15DrawMiniCounteriiiii
0002d040 S __Z15DrawMiniCounteriiiii.eh
00000a00 T __Z18DrawMiniFPSCounterv
0002d148 S __Z18DrawMiniFPSCounterv.eh
00000560 t __ZL9DrawDigitiiib
0002d128 s __ZL9DrawDigitiiib.eh
is this normal? Why the extra characters on the end of the function names?
In my experience most common "errors":
Was the file (really) compiled?
Was it (really) linked correctly?
Did you give the function the name you thought you did?
new Namespace issues :)
Are you sure that the miniFPSCounter.cpp file is compiled (/have been incouded in the project in the right way)? I guess what you are experiencing could be caused by a few different things,but in lack of more information I would say: Try to make sure that the cpp file is being compiled (maybe introduce a few syntax errors which would give rise to a compilation error if it is indeed compiled) and when you are sure about that, you can start checking for other stuff (suchas that it is being linked correctly, etc)
Edit: Putting checklist on top.
Related
I am trying to compile TetGen and use the code below to tetrahedralize a .ply file although I am getting these two linker errors:
LNK2005 main already defined in tetgen.obj
LNK1169 one or more multiply defined symbols found
The files that are includes in my project solution are "tetgen.h", "predicates.cxx", and "tetgen.cxx", and the folder path that these three files are in is included in my Project Properties > C/C++ > General > Additional Include Directories. I did the same for the "monkey.ply" file as well.
This is all the code in my main file:
#include "tetgen.h"
int main()
{
tetgenio in, out;
in.firstnumber = 0;
in.load_ply((char *)"monkey.ply");
tetgenbehavior* b = new tetgenbehavior();
tetrahedralize(b, &in, &out);
}
Here are the "tetgen.h", "predicates.cxx", and "tetgen.cxx" files I'm using : https://minhaskamal.github.io/DownGit/#/home?url=https://github.com/libigl/tetgen
I researched these errors and looked around a great amount but can't see why this is occurring. Any help would be greatly appreciated.
LNK2005 main already defined in tetgen.obj
This message tries to tell you that your tetgen library contains the main function. Your "main file" also contains a main function. This is a conflict. You should remove your main function from your code, and read the documentation of the tetgen library on how to provide a replacement. Typically, libraries which define their own main functions require you to rename your main to have some other name, which the documentation should clearly specify.
#include "tetgen.h"
int main_replacement_called_by_tetgen()
{
...
}
For anyone who may have this issue in the future with TetGen: The problem was that the TETGEN_LIBRARY flag needed to be defined in tetgen.h. I knew this, but every time I defined the flag, it would cause memory errors without fail. So, I kept TETGEN_LIBRARY undefined to avoid the memory error. Turns out, with TETGEN_LIBRARY defined, it will work. The problem was that "monkey.ply" did not exist/was in the wrong folder. Because "monkey.ply" did not exist it threw an unhandled exception. Why TetGen does not have a simple handle to check if a file exists before it tries to load it or not is beyond me. But that fixed things.
I have two short files located in the same directory. The contents of each are shown below.
File test.cpp contains:
int main()
{
#include <test.h>
}
File test.h contains:
syntax_error
Upon compiling test.cpp with either g++ or clang++, I get an error which is expected.
test.cpp:3:11: error: 'test.h' file not found with <angled> include; use
"quotes" instead
#include <test.h>
^~~~~~~~
"test.h"
However, I also get a second error which seems to contradict the first error.
In file included from test.cpp:3:
./test.h:1:1: error: use of undeclared identifier 'syntax_error'
syntax_error
^
Essentially, the first error reports that the compiler cannot find the file test.h, and the second reports a syntax error in the file that the compiler reported it could not find.
These are the only two errors generated.
I understand why the compiler reports the first error and that I should use quotes with #include in this case. Why, though, does the compiler say it cannot find the file when it clearly has found it? And, why would it continue to report errors in the "unfound" file?
This is a feature, not a bug.
The idea is that if the error is trivial (like a missing semicolon), then the compiler will try to continue compiling as if you had already fixed the error. This enables you to fix multiple errors in one go. This is especially useful when compiling your code takes a long time.
Imagine fixing a missing semicolon, recompiling for five hours, just so that the compiler finds another missing semicolon. And then you have to recompile again. That would be very frustrating, no?
Basically, the compiler will try to recover from any errors as far as it is able to, to be able to report as much errors as possible. Most compilers have a flag for this.
Why, though, does the compiler say it cannot find the file when it clearly has found it?
The compiler found the file yes, that's why it gave you a hint to use "" instead of <>. If it hadn't, it might not have given you the hint. Still, the compiler is not allowed to compile your code correctly, because your code is ill-formed.
As an analogy, just because the compiler found a missing semicolon, that doesn't mean that it can just compile the code with that missing character (if it tries to be Standards compliant). It will however recover and try to find other errors, if any.
I've been trying to compile a Borland C++ Builder 6 project, but linker dies with exact following error:
[Linker Fatal Error] Fatal: Unable to open file '.OBJ'
Strange thing about it is that it doesn't give any file name except the extension. It looks like an internal bug, though googling for it didn't give any results. Has anyone encountered this error?
== SOLVED ==
It was actually an invalid compiler directive in one of the sourcefiles which caused linker command line to be corrupted. Thanks for help.
Check for illegal whitespace characters in your Linker command line.
If you don't find any, post your linker command line here (Off the top of my head found in Project -> Options -> Linker -> Command Line).
I've never used Borland C++ Builder, but that might sound like a broken project or a corrupted object file - I guess you have not had any compilation error.
A few steps you may want to take:
- rebuild the project
- check the exact command-line used to invoke the linker, and look for strange things in the custom project settings (in such a thing exists).
If you indeed find some strange things in the command-line, hand-editing the project file (kids, don't do this at home) to remove the offending part may be the last resort before building up a new project.
Ive seen this before with visual studio, normally if i stop the compiler building while its in the linking process, not sure if borland generates obj files during its linking process? have a search in your project directory, and delete the obj files possibly in a folder called "intermediate" and try again
I suspect whitespace or other characters such as - or + on your command line.
This is a really weird problem. I'm compiling a C++ project on Solaris 10, with cc "Sun C 5.7 2005/01/07" and Bison 1.25 (if that matters). After finally getting the libs built, it still fails to link the executables, with following error message:
Undefined first referenced
symbol in file
PointZERO /export/build/proj/lib/libMainLib.so
ld: fatal: Symbol referencing errors. No output written to bin/the_exe
Does anyone know this "PointZERO" symbol? It's not in my code; nor is the string contained in any of my libraries. I've never seen this name before. And I haven't found anything about this on Google...
Well, ouch... The error was induced by an #include <...> statement in one of the source files, which (for unknown reasons) was used to include a file from a completely different project.
Very embarrassing for a number of reasons. Lesson: more thorough code reviews before checking in.
I'm getting these errors while linking, both messages have to do with the same object file.
CALL16 reloc at 0x5f8 not against global symbol
and
could not read symbols: Bad value
The 2nd message seems to be the reason I'm getting the CALL16 error, but the file compiles just fine.
Any tips on fixing this?
FYI, I'm cross compiling for a MIPS target and using gcc 4.1.2
EDIT: No luck so far:
Here are my flags used:
-fPIC,-Wl,-rpath,-Wl,-O1
I've also tried the following without success:
-mno-explicit-relocs
-mexplicit-relocs
-mlong-calls
-mno-long-calls
-mxgot
-mno-xgot
Meanwhile, I'll go back to the source at this point and investigate more.
Aha!
Thanks to a colleague of mine, we found the issue.
Here was the issue:
There was a forward declaration/prototype of a function.
void FooBarIsBest(void);
Later on in the file the function was defined.
static void FooBarIsBest(void)
{
// do the best
}
The issue here was that in the prototype the keyword static was left out. So it was like a whole new function was being defined.
The CALL16 reference is used by gcc for relocatable code. The assembly code of the file showed that CALL16 was being used on this function... Which is wrong, as this function is local.
Interestingly, this code used to compile & link just fine with an older version of gcc (3.2.2).
Another lessoned learned. :)
Try -mlong-calls flag to the compiler.
Also see the manual for more specific MIPS options.