This question already has answers here:
What is an undefined reference/unresolved external symbol error and how do I fix it?
(39 answers)
Closed 7 years ago.
I was trying to use glew32.lib file to link in my project, than I compile Glew source by myself to get glew.a file. Now, I have these link errors in my project:
g++ -o Chapter10(OpenCLTest).exe src\Chapter10(OpenCLTest).o -lopengl32 -lglew -lglut32 -lglu32 -lopencl
src\Chapter10(OpenCLTest).o:Chapter10(OpenCLTest).cpp:(.text+0x167): undefined reference to `_imp____glewBindBuffer'
src\Chapter10(OpenCLTest).o:Chapter10(OpenCLTest).cpp:(.text+0x39a): undefined reference to `_imp__glewInit'
src\Chapter10(OpenCLTest).o:Chapter10(OpenCLTest).cpp:(.text+0x3a7): undefined reference to `_imp__glewIsSupported'
src\Chapter10(OpenCLTest).o:Chapter10(OpenCLTest).cpp:(.text+0x48a): undefined reference to `_imp____glewGenBuffers'
src\Chapter10(OpenCLTest).o:Chapter10(OpenCLTest).cpp:(.text+0x495): undefined reference to `_imp____glewBindBuffer'
src\Chapter10(OpenCLTest).o:Chapter10(OpenCLTest).cpp:(.text+0x4dd): undefined reference to `_imp____glewBufferData'
src\Chapter10(OpenCLTest).o:Chapter10(OpenCLTest).cpp:(.text+0x50b): undefined reference to `_imp____glewGetBufferParameteriv'
src\Chapter10(OpenCLTest).o:Chapter10(OpenCLTest).cpp:(.text+0x1d67): undefined reference to `_imp____glewBindBuffer'
src\Chapter10(OpenCLTest).o:Chapter10(OpenCLTest).cpp:(.text+0x1d7f): undefined reference to `_imp____glewDeleteBuffers'
src\Chapter10(OpenCLTest).o:Chapter10(OpenCLTest).cpp:(.text+0x1d95): undefined reference to `_imp____glewBindBuffer'
src\Chapter10(OpenCLTest).o:Chapter10(OpenCLTest).cpp:(.text+0x1dad): undefined reference to `_imp____glewDeleteBuffers'
src\Chapter10(OpenCLTest).o:Chapter10(OpenCLTest).cpp:(.text+0x2078): undefined reference to `_imp____glewBindBuffer'
collect2: ld returned 1 exit status
It is good to solve this problem but by the way I want to ask are there any other opengl implementaions of gl extentions?
I'm afraid you can't use glew.lib with g++ (because .lib is a proprietary Microsoft format). These errors you get are missing function entry points, meaning that you didn't compile GLEW correctly (the required functions are not exported in your .so - need to know more details in order to be able to solve this issue).
As for the other part of the question, you can try GLEH. It is still in the development phase and may need some tweaking to work for you, but we've been using it quite successfuly in linux so it shouldn't be too bad.
(I know this is a bit late, but I figured it might solve someone else's problem, so) I had a very similar problem compiling a program that linked to GLEW dynamically. It turns out that I had overlooked the libglew32.dll.a file - that also needed to be present (in addition to libglew32.a and glew32.dll that I had previously copied to my project folder.)
You could try GLee which essentially does the same thing as GLEW.
Strange nobody has said anything about this. By default on Windows, the GLEW headers use declspec(dllimport) for all of the external functions, which mangles all of their names. This is why all of the missing external symbol names all have _imp____ at the front.
If you wan't to use a static build of GLEW (you mentioned something about libglew.a), define GLEW_STATIC during the build of GLEW and during the build of your application. This will unmangle the names for static linking.
If you want to link to a shared library version of GLEW, make sure to build GLEW with GLEW_BUILD. I'm not sure if this is necessary with gcc but it is if the library is built with MSVC.
Furthermore, the GNU toolchain actually supports Microsoft's .lib format for linking. source
You may find it easiest to just compile GLEW yourself or even include it in your project. It is only one source file and a few headers. To compile the library manually, use something along the lines of gcc -shared -o libGLEW.dll -Wl,--out-implib=libGLEW.dll.a -O2 -DGLEW_BUILD glew.c. To get the static version use something like gcc -c -O2 -DGLEW_STATIC glew.c instead.
Related
I have installed the GMP library and try to cross-compile with mingw-w64-posix.
My Library is in /usr/local/lib.
My compile command looks like the following:
x86_64-w64-mingw32-g++-posix src/factorial.cpp -o bin/factorial.win.o -I/usr/local/include -L/usr/local/lib -lgmp -lgmpxx
It throws an undefined reference error:
(I can remove the whole block from -L...., same error. Seems like the library doesnt link for some reason)
/usr/bin/x86_64-w64-mingw32-ld: /tmp/ccxY03WS.o:factorial.cpp:(.text$_ZN23__gmp_binary_multiplies4evalEP12__mpz_structPKS0_S3_[_ZN23__gmp_binary_multiplies4evalEP12__mpz_structPKS0_S3_]+0x27): undefined reference to `__gmpz_mul'
/usr/bin/x86_64-w64-mingw32-ld: /tmp/ccxY03WS.o:factorial.cpp:(.text$_ZN23__gmp_binary_multiplies4evalEP12__mpz_structPKS0_l[_ZN23__gmp_binary_multiplies4evalEP12__mpz_structPKS0_l]+0x26): undefined reference to `__gmpz_mul_si'
/usr/bin/x86_64-w64-mingw32-ld: /tmp/ccxY03WS.o:factorial.cpp:(.text$_ZN10__gmp_exprIA1_12__mpz_structS1_E7init_siEl[_ZN10__gmp_exprIA1_12__mpz_structS1_E7init_siEl]+0x1a): undefined reference to `__gmpz_init_set_si'
/usr/bin/x86_64-w64-mingw32-ld: /tmp/ccxY03WS.o:factorial.cpp:(.text$_ZN10__gmp_exprIA1_12__mpz_structS1_EC1EOS2_[_ZN10__gmp_exprIA1_12__mpz_structS1_EC1EOS2_]+0x2e): undefined reference to `__gmpz_init'
/usr/bin/x86_64-w64-mingw32-ld: /tmp/ccxY03WS.o:factorial.cpp:(.text$_ZN10__gmp_exprIA1_12__mpz_structS1_ED1Ev[_ZN10__gmp_exprIA1_12__mpz_structS1_ED1Ev]+0x14): undefined reference to `__gmpz_clear'
collect2: error: ld returned 1 exit status
However if i change my compiler to g++ instead everything works fine.
OK -
The link errors (__gmpz_init, __gmpz_clear, etc.) are GMP "internals". They're supposed to come from libgmp, the C-language base library.
The code that's referencing them (.text$ZN23__gmp_binary_multiplies4evalEP12__mpz_structPKS0_S3[ZN23__gmp_binary_multiplies4evalEP12__mpz_structPKS0_S3], etc.) is "name mangled" C++.
I suspect the problem is that your "gmpxx" library was built with a different C++ compiler, that has a different "name mangling" convention than MinGW.
SOLUTION:
Download the complete libGMP source (e.g. from https://gmplib.org/, and rebuild EVERYTHING (including libgmpxx) with your libmingw-w64-posix++ C++ cross-compiler.
ADDENDUM:
I downloaded gmp-6.2.1 source, and found __gmpz_clear here:
gmp-6.2.1\gmp-h.in
#define mpz_clear __gmpz_clear
__GMP_DECLSPEC void mpz_clear (mpz_ptr);
"gmp-h.in" is a template used by the project's "autoconf", to generate the libGMP source files for the specified target environment.
Which, in turn, means:
The project you started out with (in your original question) wasn't configured for MinGW
... and ...
You didn't run "configure" correctly when you tried building from source.
SUGGESTION:
Try building libGMP from source again. DELETE everything, re-extract from the libGMP tarball, and carefully follow the INSTALL instructions:
./configure
make
make check <= VERY IMPORTANT!!
make install
I'm curious about your build environment (Windows? Linux?), compiler (exact MinGW version) and target (if you're building on a Windows workstation, do you want to run your GMP app as a Windows .exe)?
I'm getting really frustrated now with trying to link this glew Library
Here's the build log:
g++ -o test.exe "src\\test.o" -lglew32 -lglfw -lglu32 -lopengl32
src\test.o: In function `main':
C:\dev\test\Debug/../src/test.cpp:31: undefined reference to `_imp__glewInit#0'
C:\dev\test\Debug/../src/test.cpp:41: undefined reference to `_imp____glewGenVertexArrays'
C:\dev\test\Debug/../src/test.cpp:42: undefined reference to `_imp____glewBindVertexArray'
I've tried moving around which libraries go first in the build command.
This seems to be an issue that others on the internet are having but i cant seem to find any of them that have fixed it
Ok I know it's a bit wierd be answering my own question but here was the issue:
Apparently the errors were occuring in two areas
For a starter, i didn't need glu32 only opengl32 as i beleive glew handled this itself
Secondly, for some wierd reason i had to call
#define GLEW_STATIC
manually before I imported
Ok, newb question here.
I'm trying to compile simple_xy_wr.f90 -- a netCDF example program -- using gfortran on Ubuntu, and I must be doing something pretty silly; I don't have much experince compiling Fortran.
First, I've got the libnetcdf-dev package installed, which includes files like
/usr/lib/libnetcdf.a
/usr/lib/libnetcdff.a
/usr/include/netcdf.mod
So, I've tried to compile the code with (various command like)
f95 -o xy -I/usr/include/ -L/usr/lib/ -lnetcdff -lnetcdf simple_xy_wr.f90
and I get the following output
/tmp/ccE6g7sr.o: In function `check.1847':
simple_xy_wr.f90:(.text+0x72): undefined reference to `__netcdf_MOD_nf90_strerror'
/tmp/ccE6g7sr.o: In function `MAIN__':
simple_xy_wr.f90:(.text+0x284): undefined reference to `__netcdf_MOD_nf90_create'
simple_xy_wr.f90:(.text+0x2b6): undefined reference to `__netcdf_MOD_nf90_def_dim'
simple_xy_wr.f90:(.text+0x2e8): undefined reference to `__netcdf_MOD_nf90_def_dim'
simple_xy_wr.f90:(.text+0x432): undefined reference to `__netcdf_MOD_nf90_def_var_manydims'
simple_xy_wr.f90:(.text+0x468): undefined reference to `__netcdf_MOD_nf90_enddef'
simple_xy_wr.f90:(.text+0x4aa): undefined reference to `__netcdf_MOD_nf90_put_var_2d_fourbyteint'
simple_xy_wr.f90:(.text+0x4cb): undefined reference to `__netcdf_MOD_nf90_close'
collect2: error: ld returned 1 exit status
I think that I'm including the right libraries. E.g. it seems that __netcdf_MOD_nf90_strerror should be there:
$ nm /usr/lib/libnetcdff.a | grep __netcdf_MOD_nf90_strerror
000000000004a100 T __netcdf_MOD_nf90_strerror
What am I doing wrong?
(FWIW, a few relevant references I've looked at are below.
undefined reference using netcdf library
Compiling problems with gfortran and NETCDF
Compiling and Running Fortran Programs - a basic guide
)
Ordering of object files and archives on the linker command line is very important on Unix systems since the default linker behaviour is to search for symbol definitions only in archives that follow the object file or archive, where an unresolved reference was found, referred to single pass linking.
This means that if your code references __netcdf_MOD_nf90_strerror, then the archive that contains the definition of this symbol (libnetcdff.a) must appear after the list of object files from your program. libnetcdff.a itself references symbols from the C library libnetcdf.a, hence it must be linked after libnetcdff.a. So the correct link order is:
/tmp/ccE6g7sr.o libnetcdff.a libnetcdf.a
where /tmp/ccE6g7sr.o is the temporary object file that the assembler produces from the compiled source file. The correct command line to compile your code is then:
f95 -o xy -I/usr/include/ simple_xy_wr.f90 -lnetcdff -lnetcdf
In this case the linker is not called directly, rather the compiler does it. GCC compilers pass all link-related things in the same order to an intermediate utility called collect2 which then calls the actual linker ld.
Note that if shared object versions of the netCDF library archives are also present (i.e. there are libnetcdff.so and libnetcdf.so), then the linker would prefer them to the static archives (unless static linking is enabled with the -static option) and the final link phase would be handled to the run-time link editor (RTLD) (/lib64/ld-linux-x86-64.so.2 on Ubuntu). In this case the same command line as in your question would actually succeed without link errors, despite the fact that both libraries are positioned before the code that references them, as the missing symbol references would be resolved by the RTLD while it is loading the executable file.
In Ubuntu 12.10, the order of the libraries is the trick (as Hristo suggested):
angelv#palas:~$ gfortran -o xy -I/usr/include/ -L/usr/lib/ -lnetcdf -lnetcdff simple_xy_wr.f90
/tmp/ccj95anF.o: In function `check.1847':
simple_xy_wr.f90:(.text+0x72): undefined reference to `__netcdf_MOD_nf90_strerror'
/tmp/ccj95anF.o: In function `MAIN__':
simple_xy_wr.f90:(.text+0x284): undefined reference to `__netcdf_MOD_nf90_create'
simple_xy_wr.f90:(.text+0x2b6): undefined reference to `__netcdf_MOD_nf90_def_dim'
simple_xy_wr.f90:(.text+0x2e8): undefined reference to `__netcdf_MOD_nf90_def_dim'
simple_xy_wr.f90:(.text+0x432): undefined reference to `__netcdf_MOD_nf90_def_var_manydims'
simple_xy_wr.f90:(.text+0x468): undefined reference to `__netcdf_MOD_nf90_enddef'
simple_xy_wr.f90:(.text+0x4aa): undefined reference to `__netcdf_MOD_nf90_put_var_2d_fourbyteint'
simple_xy_wr.f90:(.text+0x4cb): undefined reference to `__netcdf_MOD_nf90_close'
collect2: error: ld returned 1 exit status
angelv#palas:~$ gfortran -o xy -I/usr/include/ simple_xy_wr.f90 -L/usr/lib/ -lnetcdf -lnetcdff
angelv#palas:~$ ./xy
0 12 24 36
*** SUCCESS writing example file simple_xy.nc!
i builded my boost library with bjam, and then moved all the .a files into c:\Server\libs\boost_1_46_0\lib
if i want to compile my program there is some error:
the compile command
g++ -Ic:\Server\libs\boost_1_46_0\ -Lc:\Server\libs\boost_1_46_0\lib\ -lboost_thread-mgw45-mt-1_46 -o try1 try1.cpp
the errors
C:\Users\FEHERG~1\AppData\Local\Temp\ccB46To7.o:try1.cpp:(.text+0xe9): undefined
reference to `_imp___ZN5boost6thread4joinEv'
C:\Users\FEHERG~1\AppData\Local\Temp\ccB46To7.o:try1.cpp:(.text+0x120): undefine
d reference to `_imp___ZN5boost6threadD1Ev'
C:\Users\FEHERG~1\AppData\Local\Temp\ccB46To7.o:try1.cpp:(.text+0x138): undefine
d reference to `_imp___ZN5boost6threadD1Ev'
C:\Users\FEHERG~1\AppData\Local\Temp\ccB46To7.o:try1.cpp:(.text$_ZN5boost11this_
thread18interruptible_waitEm[boost::this_thread::interruptible_wait(unsigned lon
g)]+0x40): undefined reference to `_imp___ZN5boost11this_thread18interruptible_w
aitEPvNS_6detail7timeoutE'
C:\Users\FEHERG~1\AppData\Local\Temp\ccB46To7.o:try1.cpp:(.text$_ZN5boost6thread
C1IPFvvEEET_NS_10disable_ifINS_14is_convertibleIRS4_NS_6detail13thread_move_tIS4
_EEEEPNS0_5dummyEE4typeE[boost::thread::thread<void (*)()>(void (*)(), boost::di
sable_if<boost::is_convertible<void (*&)(), boost::detail::thread_move_t<void (*
)()> >, boost::thread::dummy*>::type)]+0x23): undefined reference to `_imp___ZN5
boost6thread12start_threadEv'
collect2: ld returned 1 exit status
can anybody help me what is the problem in this problem?
i followed this tutorial: http://antonym.org/2009/05/threading-with-boost---part-i-creating-threads.html
so this is the source: http://pastebin.com/YqCPLNwU
UPDATE:
i think the error is not lining the library, the error is in the library.
i built it with bjam with toolchain=gcc multithread options.
UPDATE
here is the objdump http://pastebin.com/4fpqYb7d
UPDATE
i found that the problem is that the linker wants to link with dynamic linking or something like this.
Code Blocks, MinGW, Boost, and static linking issues
there "Jack Kelly" says that i need to add #define BOOST_THREAD_USE_LIB at the beginning of my source file. but this not helps to me. how can i link a library statically? (the -static not helped as well)
adding #define BOOST_THREAD_USE_LIB at the beginning works.
Remember to link also boost libs listed in the errors (boost system in my case).
Move the -lboost_thread-mgw45-mt-1_46 option to the end of the command line (after try1.cpp). (From chat.)
This might be relevant https://svn.boost.org/trac/boost/ticket/4614
I am using MinGW compiler on Windows to compile my C++ application with sockets. My command for linking looks like:
g++.exe -Wall -Wno-long-long -pedantic -lwsock32 -o dist/Windows/piskvorky { there are a lot of object files }
and I have also tried
g++.exe -Wall -Wno-long-long -pedantic -lws2_32 -o dist/Windows/piskvorky { there are a lot of object files }
but in both case I get this error:
build/Windows/MinGW-Windows/src/utils/tcpunit.o:tcpunit.cpp:(.text+0x33): undefined reference to `closesocket#4'
build/Windows/MinGW-Windows/src/utils/tcpunit.o:tcpunit.cpp:(.text+0xd0): undefined reference to `send#16'
build/Windows/MinGW-Windows/src/utils/tcpunit.o:tcpunit.cpp:(.text+0x1ee): undefined reference to `recv#16'
build/Windows/MinGW-Windows/src/utils/tcpdevice.o:tcpdevice.cpp:(.text+0x184): undefined reference to `WSAStartup#8'
build/Windows/MinGW-Windows/src/utils/tcpdevice.o:tcpdevice.cpp:(.text+0x1a5): undefined reference to `closesocket#4'
build/Windows/MinGW-Windows/src/utils/tcpdevice.o:tcpdevice.cpp:(.text+0x1cb): undefined reference to `closesocket#4'
build/Windows/MinGW-Windows/src/utils/tcpdevice.o:tcpdevice.cpp:(.text+0x1d3): undefined reference to `WSACleanup#0'
build/Windows/MinGW-Windows/src/utils/tcpdevice.o:tcpdevice.cpp:(.text+0x6fe): undefined reference to `bind#12'
build/Windows/MinGW-Windows/src/utils/tcpdevice.o:tcpdevice.cpp:(.text+0x724): undefined reference to `listen#8'
build/Windows/MinGW-Windows/src/utils/tcpdevice.o:tcpdevice.cpp:(.text+0x7f0): undefined reference to `gethostbyaddr#12'
build/Windows/MinGW-Windows/src/utils/tcpdevice.o:tcpdevice.cpp:(.text+0x83c): undefined reference to `socket#12'
build/Windows/MinGW-Windows/src/utils/tcpdevice.o:tcpdevice.cpp:(.text+0x86f): undefined reference to `htons#4'
build/Windows/MinGW-Windows/src/utils/tcpdevice.o:tcpdevice.cpp:(.text+0x8b5): undefined reference to `connect#12'
build/Windows/MinGW-Windows/src/utils/tcpdevice.o:tcpdevice.cpp:(.text+0x9c6): undefined reference to `accept#12'
Do you have any ideas where the problem can be, please?
Put the -lws2_32 AFTER the list of object files - GCC searches libraries and object files in the order they appear on the command line.
Just to help the other viewers out there:
gcc hello.c -o hello.o -lws2_32
With MinGW on eclipse:
Menu >> Project >> Properties >> C/C++ Build >> Settings: Register "Tool Settings" - MinGW C Linker - Miscellaneous: Lower Part "other objects"
Add: "D:\Programmierung\mingw\lib\libwsock32.a" for example. No other entries for libwsock32.a on any other properties required, especially not in Library-entries. Also no flags relating to this Lib.
In:
Menu - Project - Properties - c/c++Build - Settings: Register "Tool Settings" - MinGW C++ Linker - Miscellaneous: Lower Part "other objects"
Add: libwsock32.a from bin folder of MinGW.
Greetings I just went through the problem above....
So here are some observations first off....
I know you are refering to MinGw, but you may need cygwin to get around this, I don't know mingw that well, I know cygwin better. But I know that they are cousins of each other.
Cygwin comes with the precompiled boost libraries, but who knows of which version they are. I'm sure it's possible to check, but who has time to do that right? I do not link against cygwin boost libraries, or the mingw boost libraries, I built boost from scratch using gcc on windows (cygwin). The compile did fine.
At the time of this writing boost is on version 1.47.0 I beleive.
Already that fact that cygwin uses version (x?) and boost is 1.47.0 could be a major issue. Make you know what you are using in the way of boost.
I was using code developed on boost 1.42, and had related linker errors. The code compiled, headers were found, etc..etc... but then I got the undefined reference to WSA etc...etc...opensocket this, close socket that, etc....
So, apparantly boost, in order to do network sockets, requires a platform library, in which was found in the form of ws2_32 for windows, and socket for linux for sure.
So if you are properly using boost, and including the correct boost system libraries, you may also need an OS specific library to access some resources (networking in this case).
Linker errors dissappear after that. It's probably obvious to boost veterans what's going on here, but I was unable to find a clear answer via google.