This question already has answers here:
Why does the order in which libraries are linked sometimes cause errors in GCC?
(9 answers)
Closed 8 years ago.
I'm trying to compile a C++ application using libpq.
On my Debian it compiles fine with the following command:
g++ -I /usr/include/postgresql/ -L /usr/lib/postgresql/9.3/lib/ -lpq -o test test.cpp
On my Ubuntu I get the following error:
undefined reference to 'PQfinish'
I've included link to postgresql headers and libraries and used the -lpq. What am I missing?
Move -lpq to the end of the command line.
Linking is done in the order specified, and objects are only taken from libraries if they are needed to resolve symbols at that point. So each library has to come after any other object that needs it.
Related
This question already has answers here:
What is an undefined reference/unresolved external symbol error and how do I fix it?
(39 answers)
Closed 9 months ago.
I've been trying to figure out why those functions are undefined. I have been looking for hours trying to find a solution and haven't found any that worked. The closest one told me to download an earlier version of SDL_image, which worked but then told me SDL.dll was missing, insisting that I would need to use an older version of SDL.
Exact error message:
This is what my Makefile looks like:
g++ main.cpp -Isrc/include -Isrc/include/SDL2 -Iinclude/headers -Lsrc/lib -g -o main -lmingw32 -lSDL2main -lSDL2 -lSDL2_image
This is what my lib folder looks like:
And yes, the include folder does have SDL_image.h
Additional question, I want to put all my .dll files in a bin folder but I don't know what is telling what, where to look for them so I have them all in the src directory:
Whoever comes across this error use the VC development libraries instead of the one for MinGW. For a reason I am not aware of it works.
This question already has an answer here:
Libraries in /usr/local/lib not found
(1 answer)
Closed 2 years ago.
I try to link a shared library just installed on my system, but for some reason the output doesn't want to execute. This is my compilation:
gcc -o test test.c -lgpio
When running the output, I get the following error:
./test: error while loading shared libraries: libgpio-3.0.0.so.3: cannot open shared object file: No such file or directory
Which is weird since I have this exact file in my /usr/local/lib-folder (along with libgpio-3.0.0.so and the other shared library files). I don't have much experience with GCC, so can someone please explain what went wrong?
Your library folder is probably not in the default search path. You'll need to specify it using the -L option when you compile:
gcc -L /usr/local/lib-folder -o test test.c -lgpio
You'll also need to add this folder to the LD_LIBRARY_PATH environment variable when you run the program.
This question already has answers here:
gcc/g++: "No such file or directory"
(3 answers)
Closed 3 years ago.
I have exported
/home/username/mesa/lib
LD_LIBRARY_PATH and tried to link the libraries, but I do not know what I have type wrong to compile the program.
So I tried to compile testing.cpp with the g++ command and it says :
fatal error: osmesa.h: No such file or directory
#include <osmesa.h>
I suppose I have typed wrong the command.
The command I tried: g++ testing.cpp -L/home/username/mesa/lib/libOSMesa.so -lmesa -s -Lmesa -lOSMesa -lGLU
Source code of testin.cpp:
#include <osmesa.h>
int main()
{
return 0;
}
libraries in side /home/username/mesa/lib:
libOSMesa.la libOSMesa.so libOSMesa.so.8 libOSMesa.so.8.0.0
You must pass the include directories as well, use the -I compiler option.
This is because the compiler will by default not look for headers in your home directory (it will do that for system installed libraries in /usr/include).
Closed. This question needs debugging details. It is not currently accepting answers.
Edit the question to include desired behavior, a specific problem or error, and the shortest code necessary to reproduce the problem. This will help others answer the question.
Closed 5 years ago.
Improve this question
Неllо еvеrybоdу!
I try to compile program with MinGW on Linux:
i686-w64-mingw32-g++ -static -mwindows ./obj/CFLF.o ./obj/resources.o -o ./bin/CFLF.exe
and catch this output:
./mingw-w64-crt/crt/crtexe.c:171: multiple definition of `WinMainCRTStartup'
/usr/lib/gcc/i686-w64-mingw32/6.2-win32/../../../../i686-w64-
mingw32/lib/../lib/crt2.o:./mingw-w64-crt/crt/crtexe.c:171: first
defined here
./obj/CFLF.o: In function `mainCRTStartup':
./mingw-w64-crt/crt/crtexe.c:199: multiple definition of `mainCRTStartup'
/usr/lib/gcc/i686-w64-mingw32/6.2-win32/../../../../i686-w64-
mingw32/lib/../lib/crt2.o:./mingw-w64-crt/crt/crtexe.c:199: first
defined here
./obj/CFLF.o:cygming-crtbegin.c:(.text+0x500): multiple definition of `__gcc_register_frame'
/usr/lib/gcc/i686-w64-mingw32/6.2-win32/crtbegin.o:cygming-crtbegin.c:
(.text+0x0): first defined here
./obj/CFLF.o:cygming-crtbegin.c:(.text+0x560): multiple definition of __gcc_deregister_frame'
/usr/lib/gcc/i686-w64-mingw32/6.2-win32/crtbegin.o:cygming-crtbegin.c:
(.text+0x60): first defined here
./obj/CFLF.o:crtexe.c:(.CRT+0x10): multiple definition of `mingw_pcinit'
/usr/lib/gcc/i686-w64-mingw32/6.2-win32/../../../../i686-w64-
mingw32/lib/../lib/crt2.o:./mingw-w64-crt/crt/crtexe.c:118: first
defined here
./obj/CFLF.o:crtexe.c:(.data+0x0): multiple definition of `__mingw_winmain_nShowCmd'
/usr/lib/gcc/i686-w64-mingw32/6.2-win32/../../../../i686-w64-
mingw32/lib/../lib/crt2.o:./mingw-w64-crt/crt/crtexe.c:118: first
defined here
./obj/CFLF.o:crtexe.c:(.CRT+0x4): multiple definition of `mingw_pcppinit'
/usr/lib/gcc/i686-w64-mingw32/6.2-win32/../../../../i686-w64-
mingw32/lib/../lib/crt2.o:./mingw-w64-crt/crt/crtexe.c:118: first
defined here
/usr/lib/gcc/i686-w64-mingw32/6.2-win32/crtbegin.o:cygming-crtbegin.c:
(.text+0x22): undefined reference to `_Jv_RegisterClasses'
Why? My code's point is WinMain, not WinMainCRTStartup or mainCRTStartup.
I write link to code, because is so big (GitHub).
P.S.: I compile this code with MinGW on Windows and hasn't this errors.
P.P.S.: Why I not use Windows? Just for base education.
The problem is that you don't create object files, but executable files that you then attempt to link together.
The command
i686-w64-mingw32-g++ ./src/main.cpp ./src/downloader.cpp -o ./obj/CFLF.o -lwinhttp
should really be
i686-w64-mingw32-g++ ./src/main.cpp -c -o ./obj/main.o
That will create the object file ./obj/main.o that you in a later stage use for the actual linking. The three big differences is that you don't provide multiple source files, you use the -c option will tells the GCC frontend program to only compile into object files, and you don't provide a library (which is only used when linking).
This needs to be done for all source files.
Then you can link all the object files together:
i686-w64-mingw32-g++ ./obj/main.o ./obj/downloader.o ./obj/resources.o -o ./bin/CFLF.exe -lwinhttp
This question already has answers here:
Linker errors when compiling against glib...?
(2 answers)
Closed 10 years ago.
I am getting very strange error whenever I am trying to compile a C++ program with FFTW3 implementation.
I am compiling as follows
g++ -O3 -lm -lfftw3 myFile.cpp -o myFileFFTW
I also included my headers file as follows
#include <math.h> #include "fftw3.h"
The error is as follows
(.text+0x63): undefined reference to `fftw_malloc'
Any suggestions?
Edit:
the suggestion by hmjd worked for me.
Linker errors when compiling against glib...?
I guess one should not work for straight 3 days otherwise mind does not work!!
Special thanks hmjd!! you saved my day and I could finish my project on time !!
I guess problem is -lfftw3 not present on your system and you are also not specifying libs correctly.
Libraries at the end of the compiler command:
gcc -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include re.c -o re -lglib-2.0
From GCC Link Options:
-llibrary
-l library
Search the library named library when linking.
(The second alternative with the library as a separate argument
is only for POSIX compliance and is not recommended.)
It makes a difference where in the command you write this option;
the linker searches and processes libraries and object files in the
order they are specified.
Thus, `foo.o -lz bar.o' searches library `z' after file foo.o but
before bar.o. If bar.o refers to functions in `z', those functions
may not be loaded.
snnippet from Linker errors when compiling against glib...?