When I want to build some OpenCV programme, it shows questions " undefined reference to cvFindHomography' so I check that which header file contains this function, so I include `...
But, it doesn't work.
You already have included the appropriate header file, otherwise you would get a compiler error and not the linker error you reported. In C++ in most cases the header files only expose the declarations of functions you want to use. In your case the definition is found in the library file. You have to tell your linker to link your program against these lib files. See "4) Configure your own projects to use OpenCV" at http://opencv.willowgarage.com/wiki/InstallGuide on how to do this for OpenCV. In addition I recommend that you increase your knowledge about the c++ build system, i.e. what does your compiler, what does your linker etc.
Related
I have a library that consists of some .c modules and some .cpp modules. I assume that's fine when the library is linked into a C++ main program. But when I attempt to link that library into a C program, I get linker errors for 'standard C++ library' modules.
gcc -o PSEQ.app -Xlinker --allow-shlib-undefined pseq.app.o -L../librep -lrep
..librep/ssuinventbean.cpp:62: undefined reference to `std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string()'
The program in question is not written in C++ - and it does not reference the ssuinventbean.cpp module. I asked a similar question about unreferenced shared library modules complaining about stuff called from there, and was told that the --allow-shlib-undefined linker flag could be used to get around that. I tried using that flag in the gcc command above, but obviously it doesn't work as advertised when the library in question is a statically linked library.
Normally, that wouldn't be a problem. I can make sure that all the modules in my application libraries have all of their references satisfied. But in this case, the reference is to the standard C++ library, which I assume would've been included if the main module of the program in question were in C++. So, catch-22? Can I not have C++ code in a library if that library will be linked against a non-C++ app - even if the .cpp module in question is never referenced? Do I have to segregate all C++ library code into its own .a files to be included only when building apps that call that code?
I found out what was causing this. It turned out that somebody had put a variable definition into a .h file that was pulled into this .cpp file. I guess it's undefined what the compiler will do with a global variable in a .h file (it could end up getting defined in multiple .c or .cpp files that pull it in).
Anyway the .cpp file in question apparently pulled in that .h file as extern "C" code, which caused something else to pull in the .cpp module (presumably to pick up the global variable). After I commented out the global variable in the .h file, the app was able to build with gcc instead of g++ on the linker line in my makefile. Problem solved.
It turns out that the link maps generated in linux by these flags are very useful. Told me that the global variable was what caused the otherwise unreferenced .cpp module to be included...
MAPFLAGS = -Xlinker --cref -Xlinker -Map=MAP
Can anyone tell me what the relevant include file would be for CreateRectRgnIndirect, CreateSolidBrush, FillRgn, CreatePen and so on?
I'm trying to work through errors like:
build/Release/Cygwin_4.x-Windows/mywindow.o:mywindow.cpp:(.text+0xc3): undefined reference
to _imp__CreateRectRgnIndirect#4' build/Release/Cygwin_4.x-Windows/mywindow.o:mywindow.cpp:
(.text+0xca): undefined reference to _imp__CreateSolidBrush#4'
I cannot find it in any Google searches I've done so far.
This is a linker error. These functions have been declared, but not defined. Therefore you need to provide a definition. That's typically done on Windows using an import library. In the case of these GDI functions it is Gdi32.lib. Supply that library to your linker and all will be well.
To find out which library to use for a specific Win32 function, consult the documentation. For instance, take CreateRectRgnIndirect. At the bottom of the documentation is a list of requirements, including the header file that declares the function, and the library that defines it.
In this case you are told to include Windows.h and link against Gdi32.lib. Clearly you already did the former because otherwise you would not have got as far as linking.
My error here was because I was missing a library in my compile command (libgdi32.a), and after that, I also wasn't putting -lgdi32 AFTER my source code, as in:
Incorrect (undefined reference error at compile time):
gcc -lgdi32 source.cpp
Correct:
gcc source.cpp -lgdi32
Found out thanks to this page:
http://www.mingw.org/wiki/Specify_the_libraries_for_the_linker_to_use
I'm trying to include some networking code into my C++ application. I downloaded CSimpleSocket and I copied all the .h and .cpp files into the directory where my main file is. Then I tried including one of the headers, but the linker just barfs up a bunch of errors, like:
[Linker error] undefined reference to CPassiveSocket::CPassiveSocket(CSimpleSocket::CSocketType)'
[Linker error] undefined reference to `CSimpleSocket::Initialize()'
[Linker error] undefined reference to `CPassiveSocket::Listen(unsigned char const*, short, int)'
[Linker error] undefined reference to `CPassiveSocket::Accept()'
and others. Everything is in one directory, so I don't think that's the problem. The code I'm using to include is #include "PassiveSocket.h". I'm using Dev-C++, if that makes any difference. I don't understand what I'm doing wrong, so if somebody could help me, that would be great.
Forgive me if this is a really dumb question, but I'm trying to learn C++, and it's not easy. Thanks for your help.
The reason you're getting this error is because your compiler can't find the binary that corresponds to the CSimpleSocket headers. It's as if you wrote
void someFunction(int someArg);
And then never provided the implementation for someFunction.
To use a third party library you need two things:
Header files (.h, .hpp, etc...)
Library files (.a, .lib, etc...)
Once you've got your header files and library files you need to put them in a place your compiler can find them. This place will vary depending on your OS, environment variables and compiler configuration.
Now that they're somewhere the compiler can find them you need to tell the compiler to use them. Header files are used with the #include command and library files are linked by providing arguments to the compiler.
Behind the scenes Dev-C++ uses the MinGW GNU GCC compiler, it invokes a command similar to g++ file1.cpp file2.cpp ... filen.cpp -o filename that tells the program g++ to compile a C++ executable named "filename" using files 1 to n. There are other flags that can be added to g++ such as telling it where to search and what to link.
The name of the CSimpleSocket library when compiled is "clsocket" so we need to find a way to configure Dev-C++ to add -lclsocket to the g++ command. I don't use Dev-C++ so I can't help you here but you're probably looking for "Linking Options" or something similar in your compile configuration. You also need to make sure the .lib and .h files are on the search path which should also be configurable in Dev-C++.
CSimpleSocket also provides an installer that should automatically create the .lib file and place the .lib and .h in places where they can be found, you should consider using that installer.
I think the complexity of this answer highlights the abysmal state of the C++ library integration ecosystem. Unfortunately there is no concept of a "module" in C++ at the time of writing.
I've been looking for solutions for this problem but them didn't work for me! I've been having a lot of problems compiling programs.
When I'm trying to execute a program in Xcode appears:
duplicate symbol _main in /Users/LauraChaparro/Library/Developer/Xcode/DerivedData/Busqueda-ercduihvfosqcoczkrgljkkmgxam/Build/Intermediates/Busqueda.build/Debug/Busqueda.build/Objects-normal/x86_64/Uno.o and /Users/LauraChaparro/Library/Developer/Xcode/DerivedData/Busqueda-ercduihvfosqcoczkrgljkkmgxam/Build/Intermediates/Busqueda.build/Debug/Busqueda.build/Objects-normal/x86_64/main.o for architecture x86_64
I don't understand why this happens! Is a C++ project... Or if you can recommend me another IDE I'll be really thankful!
It looks like you are defining a main in some of the code used to make the Uno.o object file. You can only have one main, so objects used to build libraries should not define a main. This should only be defined in the application itself.
This a linker error and it likely you would encounter it with other IDEs. You need to find where in Uno.o the main is defined and remove it.
The error you have there is a linker error. It tells you exactly what is wrong. The linker has found out that it can find the symbol *_main* defined more than one time looking through the object files. This makes it impossible for the linker to create an executable of your object files, as it have no way of telling which symbol you want to use. It continues to tell you where it found the two symbols.
Once in the Uno.o file (which I will assume come from compiling the Uno.cpp file)
another from the main.o file (from the main.cpp file)
This means, that somehow the linker can find the symbol for the main method in both files.
This could happen by:
Defining a main function both in the Uno.cpp and main.cpp
Having placed a non inline main definition in a header and including this both in the Uno.cpp file and the main.cpp file (or an include that includes another include and so on.)
As your request for another IDE I would like to remind you that neither compiler errors or linker errors are errors in the IDE, in an overwhelming number of cases the problem is that the user of the IDE has done something wrong.
This happened to me once, Make sure you include your .h file instead of your .c file in the file you don't expect your main function to be. I had my include statement having .c file and it produced the same issue .
Ok, so it's been a while, and i'm having problems with #includes
So I'm doing
#include "someheader.h"
but it's giving me
fatal error: someheader.h: No such file or directory
It's a system wide library I guess you could say.
I'm running arch linux and I installed the library from the repo, and I think the .h files are in /usr/include.
I could just copy all the header files into the folder my code is in but that would be a hack.
What is the "right" way to do this?
Edit: I wasn't correct by saying the .h files were in /usr/include, what I meant was that the library folder was in there
So, Emile Cormier's answer worked to a certain extent.
The problem now is that there are some include in the header file and it seems from the methods I'm trying to access that those includes are not happening
it's giving my the error
undefined reference to Namespace::Class::method()
Edit:
Ok so the final answer is:
#include <library_name/someheader.h>
And compile with
g++ code.cpp -llibrary_name
Sometimes, header files for a library are installed in /usr/include/library_name, so you have to include like this:
#include <library_name/someheader.h>
Use your file manager (or console commands) to locate the header file on your system and see if you should prefix the header's filename with a directory name.
The undefined reference error you're getting is a linker error. You're getting this error because you're not linking in libsynaptics along with your program, thus the linker cannot find the "implementation" of the libsynaptics functions you're using.
If you're compiling from the command-line with GCC, you must add the -lsynaptics option to link in the libsynaptics library. If you're using an IDE, you must find the place where you can specify libraries to link to and add synaptics. If you're using a makefile, you have to modify your list of linker flags so that it adds -lsynaptics.
Also the -L <path_to_library> flag for the search path needs to be added, so the linker can find the library, unless it's installed in one of the standard linker search paths.
See this tutorial on linking to libraries with GCC.
You'd use #include <someheader.h> for header files in system locations.
#include "someheader.h" would try to include the file someheader.h in the directory of your .c file.
In addition to including the header file, you also need to link in the library, which is done with the -l argument:
g++ -Wall youprogram.cpp -lname_of_library
Not doing so is the reason for the "undefined reference .. " linker errors.
The quick fix is to do use:
#include <someheader.h>
assuming that someheader.h is in the standard include locations (to find it use the command locate someheader.h in a shell. If it is in /usr/include it is in a standard location. If it is in a subdirectory of /usr/include you only need to add the part of the directory up to /usr/include in the #include directive (e.g. #include <fancy_lib/someheader.h>)
However, this is only half of the story. You also will need to set up your build system in a way that locates the given library and adds its include path (the path under which it's header files are stored) to the compiler command (for gcc that is -I/path/to/header). That way you can also build with different versions by configuring them in your build system. If the library is not header-only you will also have to add it to the linker dependencies. How this is achieved in your build system is best found out by consulting its documentation.