Edit: I have in the meantime figured this out and written a detailed answer below.
I just tried switching from the Express version of MSVC 10 to Eclipse CDT on Win7, and while configuring I encountered a problem with the following simple OpenGL code (which works fine in Visual Studio):
#define GLEW_STATIC
#include <GL/glew.h>
#include <GLFW/glfw3.h>
int main()
{
GLFWwindow* w;
if (!glfwInit())
return -1;
w = glfwCreateWindow(640, 480, "Hello World", NULL, NULL);
if (!w)
{
glfwTerminate();
return -1;
}
glfwMakeContextCurrent(w);
glewExperimental = true;
if (glewInit() != GLEW_OK)
{
return -1;
}
while (!glfwWindowShouldClose(w))
{
glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);
glfwSwapBuffers(w);
glfwPollEvents();
}
glfwTerminate();
return 0;
}
In Visual Studio, I include the library paths for GLFW and GLEW, and link (in addition to the stuff that VS does built-in) opengl32.lib, glew32s.lib, glfw3.lib, in that order.
Now if I do the same in Eclipse CDT, I can't get it to work. The following errors occur:
Info: Internal Builder is used for build
g++ "-LD:\\lib\\cpp\\glfw-3.0.1.bin.WIN32\\lib-mingw" "-LD:\\lib\\cpp\\glew-1.10.0binaries\\lib\\Release\\Win32" -o glfwcheck.exe main.o -lopengl32 -lglew32s -lglfw3
Warning: .drectve `/DEFAULTLIB:"LIBCMT" /DEFAULTLIB:"OLDNAMES" ' unrecognized
D:\lib\cpp\glew-1.10.0binaries\lib\Release\Win32/glew32s.lib(tmp/glew_static/Release/Win32/glew.obj):(.text[__glewInit_GL_VERSION_1_2]+0x4): undefined reference to `_imp__wglGetProcAddress#4'
D:\lib\cpp\glew-1.10.0binaries\lib\Release\Win32/glew32s.lib(tmp/glew_static/Release/Win32/glew.obj):(.text[__glewInit_GL_VERSION_1_3]+0x4): undefined reference to `_imp__wglGetProcAddress#4'
d:/mingw/bin/../lib/gcc/mingw32/4.8.1/../../../../mingw32/bin/ld.exe: D:\lib\cpp\glew-1.10.0binaries\lib\Release\Win32/glew32s.lib(tmp/glew_static/Release/Win32/glew.obj): bad reloc address 0x4 in section `.text[__glewInit_GL_VERSION_1_3]'
d:/mingw/bin/../lib/gcc/mingw32/4.8.1/../../../../mingw32/bin/ld.exe: final link failed: Invalid operation
collect2.exe: error: ld returned 1 exit status
Of course I tried changing the order of the three libraries, but that only mad it worse. (By the way: I think it's strange that I can't reproduce these errors above such that they're the only ones when I re-arrange the libs to the initial order. I stay at 20+ errors until I delete ALL the libs, build, and add them again.)
After fumbling around and looking through forum posts, I figured that maybe it's a problem with the GLEW binaries, and compiled them on my own with MinGW. Only this time, I get all the 'not found' errors. I don't know how I can link statically with my self-compiled GLEW, since there's now no glew32s.lib any longer, but only libglew32.a and libglew32mx.a. Linking dynamically with glew32 and putting the dll into my project folder didn't work either.
I feel like I'm doing something very wrong here in Eclipse, or just forget some additional libraries (although I once tried putting all the ones VS uses in there as well and it still did the exact same thing).
Can you help me out? :) Otherwise I think I'd have to stay with VS, or switch to Linux + make.
I figured it out, and for anyone ever encountering the issue I will try and make clear what exactly I did to finally be able to create OpenGL projects with the setup MinGW + GLEW + GLFW. In my case, I used Eclipse CDT as IDE, but I'll write down the resulting g++ command line so it should be easy to adapt to other IDE's.
I'll suppose MinGW and MSYS (can be chosen to be installed from within the MinGW GUI; thus no need to download separately) are installed.
Download GLFW and unzip it in your external libraries folder of choice (in my case, this is D:\external\cpp, so it would be something along the lines of D:\external\cpp\glfw, where I renamed the glfw-3.0.3.bin.WIN32 folder to simply glfw).
Download the GLEW source as a zip folder an unzip it, in my case it's in D:\external\cpp\glew. Now start MSYS, cd to the glew folder and invoke make all.
Step 3 should have created (among others) the files libglew32.a and glew32.dll inside the folder glew\lib. Now right click your Eclipse CDT C++ project, go to Properties - C/C++ General - Paths and Symbols. In the Includes tab, add the paths to the include folders of GLFW and GLEW. Again, for me this is D:\external\cpp\glew\include and analogous for GLFW. In Library Paths, do the same for the folders lib (GLEW) and lib-mingw (GLFW).
Now we have to add the libraries we want our project to be linked with. If you wish to link with GLEW dynamically, make sure to include the glew32.dll in the folder where your executable will be. In Eclipse CDT, that's usually the Debug (or Release) folder in your project structure. In the Libraries tab in the options window we opened before, add (the order is important!) glfw3, glew32, opengl32, glu32, gdi32. Now building the project should work hopefully. In case you want to link statically with GLEW, add the same libraries with the exception of glew32. Instead, in the project properties go to C/C++ Build - Settings and in the Tool Settings - MinGW C++ Linker - Miscellaneous tab add the path to libglew32.a to the Other objects field. In my case, this is D:\external\cpp\glew\lib\libglew32.a. Now in order for the static linking to work, you have to either add #define GLEW_STATIC above #include <GL/glew.h> or use the preprocessor command -DGLEW_STATIC. The GLEW homepage says that it's also possible to include the glew.c and glew.h files into your project in order to link statically, but somehow this didn't really work out for me.
These steps worked for me, and they produced command lines similar to the following (I have only one file named main.cpp and used static linking with GLEW), which could be useful if you're trying to figure this matter out without Eclipse CDT.
g++ -ID:\external\cpp\glew\include -ID:\external\cpp\glfw\include -c -o main.o main.cpp
g++ -LD:\external\cpp\glew\lib -LD:\external\cpp\glfw\lib-mingw -o minimalexample.exe main.o D:\external\cpp\glew\lib\libglew32.a -lglfw3 -lopengl32 -lglu32 -lgdi32
In the dynamic linking case, simply remove the part containing libglew32.a in the second line, and add -lglew32 between -lglfw3 and -lopengl32. As a little example source file, you could just use the code in my above question.
I hope I can help anyone with this, as I sure saw me having a lot of trouble figuring this out between tens of error messages of unresolved symbols and various other problems :-)
Update: I tried to go over this again some days ago and ran into problems with the pre-compiled GLFW binaries for Windows (I'm now using Win8.1). But you can just use CMake in combination with mingw32-make to compile it on your own. Also, GLEW seems to not be getting updates anymore, so I switched to glad instead. It's also possible to use MinGW-w64 to compile the libraries and your final project as 64-bit application.
Related
I'm new to unit testing in c++, and writing c++ on Linux (Mint). I'm using CodeLite as my IDE. I have found several answers on stackoverflow about linker errors, but after hours of trying various solutions I have not succeeded in implementing a solution correctly.
I installed unittest++ through apt-get. The unittest++ header files were installed in /usr/include, so I added this to the Compiler linker options in Codelite (Right click project name->Settings, Compiler):
Codelite screenshot
I then have a very simple program, which consists entirely of one main.cpp file:
#include <unittest++/UnitTest++.h>
//See if unit tests are working
TEST(MyMath) {
CHECK(false);
}
int main()
{
UnitTest::RunAllTests();
return 0;
}
Running the project at this point generates a stream of linker errors other users have experienced, for example:
main.cpp:4: undefined reference to UnitTest::CurrentTest::Details()
At this point, my understanding is that I now need to tell the g++ compiler about the object files and link them to the unittest++ files. And this is where I'm stuck. The only .o file I see is in Debug/main.cpp.o and running the command
g++ main.cpp -o main.cpp.o -Lunittest++
as well as variations with the I and o flags, but all of them return the same linker errors I get when I try to compile. I've also tried to copy every g++ line in the forums and only get various errors.
I've tried to find a solution in the g++ man pages, read about the flags I've been using and did not infer a solution. I then quickly got buried in quantity of pages in the man entry. The documentation for CodeLite and unittest++ seems woefully out of date, so I posted here on stackoverflow as a last resort.
I'm fairly certain I'm just making a rookie mistake. If someone has feedback, I'd be grateful.
In your explanation, you try to link manually with g++ -c main.cpp -o main.cpp.o -Lunittest++ , but the -L option gives the path to additional directories to search for libraries. You probably want -lunittest++ to link with the unittest++ library. That library should provide the symbols you see in the "undefined reference" errors.
As a side note, "/usr/include" should be in the default search path and there's no need to add it explicitly.
I'm trying to use c++, SDL, and SDL-image to make a game; I'm using Code::Blocks as my IDE, and I'm having some trouble.
I've downloaded the latest mingw SDL development files, and the latest mingw SDL-image development files.
I've placed all the SDL-image stuff into the same directory as the SDL stuff (merging the one into the other).
I've added the x86_64-w64-mingw32/include and x86_64-w64-mingw32/lib directories to my Code::Blocks search directories.
My linker settings are as follows:
-lmingw32
-lSDL2main
-lSDL2
-lSDL2_image
-lopengl32
-lglu32
(Obviously I'm using openGL as well, but I don't think that's involved here).
I have the correct #includes as far as I can tell:
#include <SDL2/SDL.h>
#include <SDL2/SDL_image.h>
#include <SDL2/SDL_opengl.h>
But I'm still getting the error: undefined reference to 'IMG_Load'
Here's the build log:
obj\Release\gfx_Texture.o:gfx_Texture.cpp:(.text+0xd7): undefined reference to `IMG_Load'
obj\Release\gfx_Texture.o:gfx_Texture.cpp:(.text+0x1dd): undefined reference to `SDL_FreeSurface'
obj\Release\gfx_Texture.o:gfx_Texture.cpp:(.text+0x1f4): undefined reference to `SDL_FreeSurface'
g:/program files(x86)/codeblocks/mingw/bin/../lib/gcc/mingw32/4.8.1/../../../../mingw32/bin/ld.exe: obj\Release\gfx_Texture.o: bad reloc address 0x4 in section `.text.startup'
g:/program files (x86)/codeblocks/mingw/bin/../lib/gcc/mingw32/4.8.1/../../../../mingw32/bin/ld.exe: final link failed: Invalid operation
And the actual code:
SDL_Surface* image = IMG_Load(file);
Where file is a char*.
I understand that there have been some changes to the way SDL_Surfaces work in SDL 2.0 as compared to SDL 1.2 (I'm trying to migrate, both from 1.2 to 2.0 and from MVSC to C::B), so could that have something to do with it? Am I using IMG_Load wrong?
Your help is much appreciated, and I'll supply any missing info on request if it'll clarify anything.
One more thought: The latest version of SDL is 2.0.1, yet the latest version of SDL_image is 2.0.0. Do I need those versions to match?
This happen When the program doesn't linker correctly at the executed time
for example:
asas#asas:~/SDL$ g++ -Wall SDL_program.cpp -lSDL2
/tmp/cc1eC6CK.o: InfunctionLTexture::loadFromFile(std::__cxx11::basic_string<char,std::char traits<char>, std::allocator<char> >)':
SDL_program.cpp:(.text+0x7d): **undefined reference toIMG_Load'**
As you can see above miss linker -lSDL2_image .
Is possible too, that you have SDL1.2 and SDL2 at the same root and again Code blocks hasn't linked correctly
Well don't I feel dumb. When I was working in MVC the x86 prefix meant 32-bit; for some reason, it means 64-bit in C::B, and the i686 prefix means 32-bit.
I encountered such an error, and all I did was check if my linker texts are correctly written check if you have typed "ISDL2_image" instead of "lSDL2_image"
(write small 'L' then SDL2 not cap 'I' then SDL2)for SDL2 projects.
for SDL1 just change the '2's into '1's. 👍
I am trying to use libcurl for a simple application using CodeBlocks IDE. In Codeblocks IDE, after clicking on Build Options ==> Linker Settings ==> Link Libraries ==> "Add" , the file browser only allows me to choose between *.a, *.so, *.lib, and *.dyl files. Why is it not allowing me to choose *.dll files? I downloaded the binary packages for Windows for libcurl and they all provide .dll files. This is what it looks like:
====UPDATE====
Hi I have now downloaded the following zip file for lib curl
which includes CURL Source, DLL Files, and a .lib file. It can be
found here: http://www.confusedbycode.com/curl/curl-7.34.0-win64.zip
However, I am still having issues being able to compile my source
code.
Below is my source code:
include
#include <iostream>
#include <stdio.h>
#include "curl/curl.h"
using namespace std;
int main()
{
CURL *curl;
CURLcode res;
curl = curl_easy_init();
if(curl) {
curl_easy_setopt(curl, CURLOPT_URL, "http://example.com");
/* example.com is redirected, so we tell libcurl to follow redirection */
curl_easy_setopt(curl, CURLOPT_FOLLOWLOCATION, 1L);
/* Perform the request, res will get the return code */
res = curl_easy_perform(curl);
/* Check for errors */
if(res != CURLE_OK)
fprintf(stderr, "curl_easy_perform() failed: %s\n",
curl_easy_strerror(res));
/* always cleanup */
curl_easy_cleanup(curl);
}
return 0;
}
Below is a screen shot of my CodeBlocks IDE working directory:
Below are screen shots of my build options for Linker/Compiler, and Linker Libraries:
I am not sure what is wrong with the setup. It is having trouble building. It is returning the following error messages:
Below is the latest Build Log:
-------------- Build: Debug in libcurl_c (compiler: GNU GCC Compiler)---------------
mingw32-gcc.exe -Wall -g -IC:\Users\bbb\Desktop\libcurl_packages\confused_by_code\curl-7.34.0-win64\curl-7.34.0-win64\include -c C:\Users\bbb\Desktop\workspace\libcurl_c\main.c -o obj\Debug\main.o
mingw32-g++.exe -o bin\Debug\libcurl_c.exe obj\Debug\main.o C:\Users\bbb\Desktop\libcurl_packages\confused_by_code\curl-7.34.0-win64\curl-7.34.0-win64\lib\libcurl.lib
obj\Debug\main.o: In function `main':
C:/Users/bbb/Desktop/workspace/libcurl_c/main.c:9: undefined reference to `_imp__curl_easy_init'
C:/Users/bbb/Desktop/workspace/libcurl_c/main.c:11: undefined reference to `_imp__curl_easy_setopt'
C:/Users/bbb/Desktop/workspace/libcurl_c/main.c:13: undefined reference to `_imp__curl_easy_setopt'
C:/Users/bbb/Desktop/workspace/libcurl_c/main.c:16: undefined reference to `_imp__curl_easy_perform'
C:/Users/bbb/Desktop/workspace/libcurl_c/main.c:19: undefined reference to `_imp__curl_easy_strerror'
C:/Users/bbb/Desktop/workspace/libcurl_c/main.c:23: undefined reference to `_imp__curl_easy_cleanup'
collect2.exe: error: ld returned 1 exit status
Process terminated with status 1 (0 minutes, 1 seconds)
6 errors, 0 warnings (0 minutes, 1 seconds)
A DLL (dynamic link library) is searched for and loaded by your program at runtime. To
make this happen automatically, you do not link the .dll itself (you can't). You link the matching import library, with extension .lib.
The import library for libcurl.dll is libcurl.lib. If you have downloaded and extracted cURL, say, into C:\develop\curl-7.34.0-win32, then you will find the import library at
C:\develop\curl-7.34.0-win32\lib\libcurl.lib. You should add this file to the libraries
for your Code::Blocks project.
The project will then link (unless it has other problems), but in order for it to run successfully it will have to find libcurl.dll in one of the locations that are searched for DLLs at runtime. The simplest way to ensure this is to place a copy of libcurl.dll in the directory from which your program runs. Otherwise you can decide on a location for it by studying
Dynamic-Link Library Search Order
You may have difficulty in finding the right binary package to download from
the plethora available here. Some
of them are packages of the cURL commandline tools (which you don't want)
and some of them are packages of the development binaries (which you do want)
for various platforms. Visit http://www.confusedbycode.com/curl/ and download
either curl-7.34.0-win32.zip or curl-7.34.0-win64.zip, depending on
whether you are targetting win32 or win64. Extract the archive and
find the import library and DLL in the subdirectories lib and dlls,
respectively.
Update for OP's further issues
Your program is the supplied example simple.c with the addition of a C++ header, <iostream>.
Delete your libcurl project and start again with a clean C project (not C++).
Add only 1 source file to the C project, the example simple.c or a copy of it. Don't make it a .cpp file or otherwise change it. Don't add any other files to the project.
In Build options -> Linker settings -> Link libraries add the relative path to libcurl.lib as you did before.
In Build options -> Search Directories -> Compiler (not Linker) add the relative path to the cURL include directory and nothing else (not the include\curl directory).
Do not put anything in Search directories -> Linker.
Build the project. It compiles and links for me.
Update #2
The problem now is that you are attempting to link the 64-bit curl-7.34.0-win64\lib\libcurl.lib with the 32-bit object code generated by your 32-bit toolchain, mingw32. You can't do that.
Replace your install of curl-7.34.0-win64 with curl-7.34.0-win32 from the same site. In your project, replace your\path\to\curl-7.34.0-win64\lib\libcurl.lib with your\path\to\curl-7.34.0-win32\lib\libcurl.lib and try again. The example will compile and link.
It will also run correctly, provided that it finds 32-bit libcurl.dll at runtime, and likewise the 32-bit DLLs that are dynamically loaded by libcurl.dll in turn. For the purpose of the example just copy all the DLLs from your\path\to\curl-7.34.0-win32\dlls into the same directory as the .exe. For regular development of cURL apps you would want the cURL libraries installed on the the system.
Since you chose to download 64-bit cURL in the first place, you may wish to build 64-bit
executables (although 32-bit executables will run on 64-bit hosts). You can't do that that
with your 32-bit toolchain, mingw32. You can install a 64-bit toolchain, e.g. TDM-GCC MinGW Compiler,
and configure it as an additional toolchain in C::B. Alternatively you could replace your
C::B installation with a C::B 13.12 one that has TDM-GCC pre-configured, from Sourceforge
I am trying to setup MingW and Code::Blocks on my Windows 8 64 bit laptop, and I'm facing some problem while building a main.cpp file. These are the versions that I have installed:
x86_64-w64-mingw32-gcc-4.7.4-release-win64_rubenvb.7z for MingW (4th one in that list), and
codeblocks-12.11-setup.exe for Code::Blocks.
I've set the path to mingw64\bin in the environment variable. Also, in the Code::Blocks compiler settings, I have set path for all ToolChain Executables. There are two gcc in the MingW bin path. One is - gcc.exe and other is - x86_64-w64-mingw32-gcc.exe. Same for C++ Compiler, Linker for static and dynamic libs. Now when I try to build a simple Hello World file, it shows some errors:
obj\Debug\main.o -- In function swscanf
c:\mingw\mingw64\bin\..\lib\gcc\x86_64-w64-mingw32\4.7.3\..\..\..\..\x86_64-w64-mingw32\include\wchar.h -- undefined reference to `__gxx_personality_sj0'
obj\Debug\main.o -- In function `wscanf':
c:\mingw\mingw64\bin\..\lib\gcc\x86_64-w64-mingw32\4.7.3\..\..\..\..\x86_64-w64-mingw32\include\wchar.h -- undefined reference to `__gxx_personality_sj0'
Similarly there are many errors and undefined references for - fwprintf, wprintf, std:cout, etc..
I'm sure there is some configuration problem, but I cannot find out what's the issue. Can any one take a look at the problem.
Here's the code I'm running:
#include <iostream>
using namespace std;
int main()
{
cout << "Hello world!" << endl;
return 0;
}
If you don't require 64 bit support, consider downloading "codeblocks-12.11mingw-setup.exe"
It packs its own 32 bit mingw and has everything preconfigured for you.
Otherwise, if you still need to compile amd64 apps:-
Assuming you extracted to D:\Mingw64, under the "Tool Chain Executables" tab, set the "Compiler's Installation Directory" to "D:\Mingw64\bin", Then click auto-detect to check whether code::blocks likes what it finds.
If everythings Ok, make sure the rest of the fields are as follows:-
C compiler: x86_64-w64-mingw32-gcc.exe
C++ compiler: x86_64-w64-mingw32-g++.exe
Linker for dynamic libs: x86_64-w64-mingw32-g++.exe
Linker for static libs: x86_64-w64-mingw32-ar.exe
Debugger: GDB/CDB Debugger...
Ressource compiler: x86_64-w64-mingw32-windres.exe
Make program: mingw32-make.exe
Click on the "Additional Paths" tab and enter the following line:- (the path is correct for ver 4.7.4,the one you downloaded. It ends with 4.7.3)
D:\Mingw64\libexec\gcc\x86_64-w64-mingw32\4.7.3\
Click on the "Search directories" tab to the imediate left "Toolchain Executables"
Add the following paths:-
D:\Mingw64\include
D:\Mingw64\x86_64-w64-mingw32\include
D:\Mingw64\x86_64-w64-mingw32\include\c++\4.7.3
D:\Mingw64\x86_64-w64-mingw32\include\c++\4.7.3\backward
D:\Mingw64\x86_64-w64-mingw32\include\c++\4.7.3\x86_64-w64-mingw32
D:\Mingw64\lib\gcc\x86_64-w64-mingw32\4.7.3\include
Click on the "linker" tab and add the following paths:-
D:\Mingw64\Lib
D:\Mingw64\x86_64-w64-mingw32\lib
And finally click on the "Compiler Settings tab", Click on "Other options" and add:-
-m64
One last thing-> remember to save those settings to disk!
If it crashes while you test this new config, you might wish you had!
Do this (I think) either by "File->Save Everything" or restarting code::blocks ...without another instance running.
Try compiling something then share the outcome
Peace! Dear brother, I think you need this:
(1)
std::cout << "Hello world!" << std::endl;
You need to put "std::function_name" whenever you are using a predefined function from iostream.h, because this is you way access it in GCC, which Code::Blocks uses.
(2) Try it compiling by omitting "using namespace std;" from your code.
Because I've compiled C and C++ code many times in Code::Blocks on 32-bit Windows XP, and it did!
(3) Make sure the path is set to the directory "mingw\bin".
(4) Ensure if you have 64-bit MinGW installed and path set to its "bin" directory (if you want to compile for 64-bit). It will compile for 64-bit by default.
(5) Try the flags/arguments "-m32" and "-m64" for compiling for 32- and 64-big respectively.
So I'm developing my project in Eclipse in Ubuntu 10.04. I have the following lines of code:
#include <pty.h>
pid_t pid;
int master;
pid = forkpty(&master, NULL, NULL, NULL);
But when I try to build it within Eclipse, I get the error:
undefined reference to 'forkpty'
Any idea how to solve this problem?
You need -lutil command line argument (to use libutil shared library).
For Eclipse:
http://zetcode.com/articles/eclipsecdevelopment/
Select Project Properties. Expand the C/C++ Build tab. Select settings. From the Tool Settings tab, expand the GCC C Linker option. Click on libraries. Add the /usr/lib/libutil.so to the Libraries window. Notice, that this path may be different on your system.
That's a linking error; you're missing the util library. Do this to build on the command line:
g++ myprogram.cpp -lutil
Eclipse should have project-level settings for listing the libraries to link against.
I came upon this issue when I was trying to install delegate
So if you are trying to make delegate and getting error
undefined reference to `forkpty'
so edit _-forkpty.c file inside maker folder
vim maker/_-forkpty.c and add
#include <util.h>
make clean
make