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
Related
I'm trying to compile my c++ code with another libc with g++.
To do that, I used the rpath option to provide the path to the new libc.
I have also provided the dynamic-linker option to provide the corresponding linker.
The problem is that I'm getting this error:
path_to_old_libc/crt1.o: In function `_start': undefined reference to `__libc_csu_fini'
Thus, I also have to give the path to the new crt file located at path_to_new_libc
The problem is that I don't see any option in the manual that would allow to do that. I though about the nostartupfile or nostdlib options, but that would just ignore the crt file which is not what I want.
So far, the compilation looks like that:
g++ -Wl,--dynamic-linker=/.../.../.../glibc-2.22/build/elf/ld-linux-x86-64.so.2 -Wl,-rpath,/buildroot/output/build/glibc-2.22/build ...
Therefore, I'm looking for a way to add the right crt file.
Thank you in advance for your help
I have a bunch of arm assembly, C and C++ files. gcc is trying to link them, but these are for an embedded project.
I am not using any external libraries, all code that is being used was written by me. An error seems to happen because I have a function called int kernel_main(void) defined in main.c that is trying to call set_LED(int value) defined in mailbox.cpp which includes the header mailbox.h (I did include the header in the main.c file).
The exact error is:
undefined reference to `__aeabi_unwind_cpp_pr1'
The way I am making my project is:
-compile all source files (.s, .c, .cpp) into object files (.o) without linking (-c), then link them all together with the use of a custom linker script.
Edit: I am going to add some information to make things more clear.
First changing all files so that all of them are C files (no cpp extensions) yields:
undefined reference to `set_LED'
It is unlikely that the issue itself is name mangling an it probably has nothing to do with CPP and C differences.
The problem is very likely to be a linker issue
This is the build process:
Compile c files, Example:
arm-none-eabi-g++ -O0 -march=armv8-a source/MainFiles/mailbox.cpp -nostartfiles -c -o objects/MainFiles/mailbox.o
(Compiling a C++ file would be identical except for the use of g++ instead of gcc)
Link everything:
arm-none-eabi-ld object1 object2... -o build/kernel.elf -T ./source/kernel.ld -I include_directory_1 -I include_directory_2 -L include_directory_1 -L indlude_directory_2
Include directories are all directories under the current one
Edit:
The error came back. Ignore the parts of this question relevant to name mangling. The error I need to fix is:
./objects/Hardware/mailbox.o:(.ARM.exidx+0x18): undefined reference to `__aeabi_unwind_cpp_pr1'
So far all I know is that this has something to do with unwinding the stack and exceptions. It seems the function is defined in libgcc. However I have used -nostdlib, I have omitted it, and in both cases the error persists. I have tried changing file extensions to .c whenever possible and to .cpp whenever possible, alas the error is always there.
It got fixed only as long as I had exactly 1 cpp file and the rest of my files were C files (this is no longer true, I tried). What triggered the error again was that I was refactoring the code and I wanted to move a couple of functions to new files.
In other words, without deleting a single file, declaring a function named wait(uint32_t time) in mailbox.cpp works, declaring it in a file called time.c (or cpp) with it's respective header declaration and including the header in mailbox.cpp breaks things. Note I don't delete the files when moving the function I simply delete the function declaration inside each file.
Adding a stub like this:
void __aeabi_unwind_cpp_pr1()
{
}
Fixes the problem and the code works. But I don't like this solution. I don't want a useless stub being called mysteriously in my code. I don't need nor want this function in my current implementation, how can I tell the compiler or the linker that they are to omit whatever they are doing that requires this function?
The solution is very simple. As it turns out exceptions are enabled by default (which is what generates the code that calls __eabi_unwind_cpp_pr1). To disable them all that is needed is to pass:
-fno-exceptions as an argument to the gcc/g++ compiler and the problem is solved.
You have a reference to this function that belongs to the C++ runtime of GCC. It's part of the exception handling. Whatever you are doing, sounds a little crazy, but anyway you can do this if you really know what you are doing. You must link against the C++ runtime libraries. That's it. Link against "libstdc++".
About the set_LED I also believe it's just about the C++ mangling, just as Justin J mentioned in the other answer.
I have seen this when mixing C and C++. Because of name mangling, the symbols will have different names internally depending on the type of the source file.
If the source for 'set_LED'is a c file, use the following in the header around the prototype and see if it helps.
#ifdef __cplusplus
extern "C" {
#endif
// function prototypes here
#ifdef __cplusplus
}
#endif
Please also add prefix "-shared" without quotes to -fno-exceptions. I am using ARM GCC version
I have working C++/Windows program compiled with Visual Studio 2008. The program consists of just two .cpp files. I am now attempting to compile and link it using MinGW. So far I have successfully compiled both source files without error, but now when I link them with the command...
g++ -o program.exe file1.o file2.o
... I get many instances of "undefined reference to.." assorted graphics related functions like:
GetStockObject, SelectObject, MoveTo, LineTo, SetPixel, TextOut, BitBlt, CreatePen etc.
I am not getting undefined references for any other types of windows call. Clearly I have missed something in my linker command line, but cant work out what.
Since this spans two (similar) prior answers, I'll add it as a separate answer, rather than as duplicate comments on those preceding answers.
Better, rather than jumping in and adding "-lgdi32", you should first add the "-mwindows" option; this tells GCC that you are building a Windows application, (its default is a "console" application type), and so causes it to automatically bind a number of additional graphics device interface specific libraries, (one of which is gdi32.dll). Only if adding this option still fails to resolve all symbols need you worry about what other non-default libraries may be needed.
All these functions are located in Gdi32.dll. You need to link Gdi32.lib to make them work. You can try:
g++ -o program.exe file1.o file2.o -L MinGW\lib -lgdi32
By the way, Microsoft documents each function extensively and names the appropriate library. For example: GetStockObject.
You can solve it like this:
For each undefined reference, look up that function at Microsoft Developer Network documentation. In your case, google for
GetStockObject msdn
The MSDN page describing the function contains at the bottom a section "Requirements". Here it lists required DLLs that you need to link to.
In case of GetStockObject, that's Gdi32.dll
Extend your command line to include -lGdi32
Retry the linking and repeat for any remaining undefined references.
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.
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.