I am trying to develop an openGL application with GLEW and GLFW on Windows using minGW. In the current directory, project/, I have the directories src/, bin/, and glfw-3.0.4.bin.WIN64/. I have the files test.cpp, glew.h, glew.c, and wglew.h in the src/ directory.
The directory ./glfw-3.0.4.bin.WIN64/include/ contains the GLFW/glfw3.h header file.
The directory ./glfw-3.0.4.bin.WIN64/lib-mingw/ contains glfw3.dll, glfw3dll.a, and libglfw3.a.
My main file, test.cpp contains,
#include "glew.h"
#include "GLFW/glfw3.h"
#include <stdio.h>
int main(int argc, char** argv) {
printf("Hello, World!\n");
glewInit();
glfwInit();
}
I am compiling the program from the project/ directory by running (split into two lines for readability)
gcc -DGLEW_STATIC -DGLFW_DLL -o ./bin/test ./src/*.cpp ./src/glew.c
-I ./glfw-3.0.4.bin.WIN64/include/ -L ./glfw-3.0.4.bin.WIN64/lib-mingw/ -lglfw3 -lopengl32
and I am getting the following error:
undefined reference to `_imp_glfwInit'
I think the problem has to do with me linking the GLFW library incorrectly. From what I understand, including the compiler option -lglfw3 will tell gcc to link ./glfw-3.0.4.bin.WIN64/lib-mingw/glfw3.dll, which contains the definition for glfwInit().
I've looked at solutions to other problems similar to mine and they suggest things such as copying the dll file to the source/binary directories and changing the order of the -l options, but none have seemed to solve the problem for me.
Your problem is that gcc follows strict library naming conventions. It attempts to find glfw3.dll.a, but finds none (because it is named glfw3dll.a - simple rename will fix your problem).
Next step it looks for libglfw3.a, and succeeds - but it is a static library, while reference declared as dynamic in header files (tricky windows DECLSPECs... this problem don't exist on e.g. linux). So, it cannot find _imp__glfwInit, because in static library it is called just glfwInit, so you getting an error.
Removing libglfw3.a is also one of options - in that case gcc will look further and eventually find glfw3.dll and use it.
Related
I am trying to compile the following code which has the headers:
#include <SDL2/SDL.h>
#include <SDL2_image/SDL_image.h>
However after running the following makefile:
g++ -std=c++11 src/main.cpp -lSDL2 -lSDL2_image
I get the following error:
fatal error: SDL2_image/SDL_image.h: No such file or directory
#include <SDL2_image/SDL_image.h>
Any suggestions? Not entirely sure about my installation of SDL_image. I am running this on Ubuntu.
This problem can be solved through installing libsdl2-image-dev package:
apt install libsdl2-image-dev
Run apt-file search SDL_image.h
The result will tell you the location of the include file.
For instance, /usr/include/SDL2/SDL_image.h was returned.
So, when you want to include SDL_image.h, write everything after the include/ in between < >.
Thus, includes should look like the following:
#include <SDL2/SDL.h>
#include <SDL2/SDL_image.h>
See the question's comments for the original discussion regarding this solution.
From SDL documentation, it says that add 'lSDL_image' to the end of the compile line.
cc -o myprogram mysource.o `sdl-config --libs` -lSDL_image
or
gcc -o myprogram mysource.c `sdl-config --libs` -lSDL_image
Here is the reference -> https://www.libsdl.org/projects/docs/SDL_image/SDL_image.html
Section 2.2 Compiling.
So for SDL2, you just need to change 'lSDL_image' to 'lSDL2_image'.
For Windows + SDL2-2.0.8 + SDL_image-2.0.4 + Codeblocks you've got the add both Runtime Binaries and Development Libraries to the compiler and linker. Or else, you'll get the error SDL2_image not found, even with having the dll in your program's directory, this occurs. Hopefully others find this helpful; I had to figure it out myself. Example: If your resources are separate, you'll be adding the two plus your standard SDL2 paths to your compiler and linker. Warning: SDL2_image.h has it's headers assuming that the headers are in the same folder as the SDL2 framework. If you get errors about the image header, include the sub-folder SDL2 from SDL framework in the path and then you should be including SDL2 in the program as: include <SDL.h> rather than include <SDL2/SDL.h>.
I'm trying to use the GLFW library, but am having difficulty with compiling a simple program. I went to the GLFW website and download the latest release, then using "How to build & install GLFW 3 and use it in a Linux project" I built and installed it.
Here's my code:
#include <GLFW/glfw3.h>
#include <iostream>
using std::cout;
using std::endl;
void GLFW_error(int error, const char* description)
{
fputs(description, stderr);
}
void run()
{
cout << "pooch" << endl;
}
int main()
{
glfwSetErrorCallback(GLFW_error);
if (!glfwInit()) exit(EXIT_FAILURE);
run();
glfwTerminate();
return 0;
}
Using the command line:
bulletbill22#ROBOTRON ~/Desktop $ g++ -std=c++11 -lglfw source.cpp
yields
source.cpp:function main: error: undefined reference to 'glfwSetErrorCallback'
glfwSetErrorCallback is taken from their tutorial for "Setting an error callback".
Inclusion of -glfw3 results in /usr/bin/ld: error: cannot find -lglfw3
Even though everything seemed to be installed correctly, I suspect the problem may lie somewhere with the installation of the GLFW library because I'm not used to CMake and don't entirely understand how it works. I'm frustrated because the answer must be simple, but I'm not sure which keywords are really relevant when googling the problem; mostly the results are people who were incorrectly compiling with CMake, which I'm not compiling with in this case.
It seems that the directories for the glfw3.h header and libglfw3.so (and/or libglfw3.a) library are not in the default path.
You can check with by adding the -v option to the g++ options. Locate the directory where the glfw3.h header is found - call this $GLFW_INCDIR - it typically ends with .../GLFW. Locate the directory where the library is found - call this $GLFW_LIBDIR. Try:
g++ -std=c++11 -I$GLFW_INCDIR source.cpp -o pooch -L$GLFW_LIBDIR -lglfw3
If all the library dependencies are satisfied, this hopefully results in a program called pooch.
One other thing: GLFW3 is a C library, and the callback function arguments are expected to be C functions. So your callback should have 'C' linkage, i.e.,
extern "C" void GLFW_error(int error, const char* description) ...
Also, if you're having trouble with cmake, you may have ccmake installed. Try ccmake . in the top-level directory of the GLFW3 package for 'interactive' configuration.
I've been working on this for a while now, and can't seem to make sense of the situation - partly bceause I don't fully understand what's going on (which is why I came here).
I'm doing a sort of boost hello world as follows:
#include <boost/thread/thread.hpp>
#include <cstdio>
void helloworld() {
std::printf("HELLO FROM A BOOST THREAD!");
}
int main(int argc, char **argv) {
boost::thread t(&helloworld);
t.join();
}
This is on Windows. I stored the Boost directory in C:\Boost. I ran bootstrap and bjam, and now have a stage/lib folder that contains all the .lib files. The lib files relating to the boost/thread library are:
libboost_thread-vc100-mt.lib
libboost_thread-vc100-mt-1_46_1.lib
libboost_thread-vc100-mt-gd.lib
libboost_thread-vc100-mt-gd-1_46_1.lib
Now I compile:
g++ -c main.cpp -I/Boost
that line works fine, I get main.o. Then:
g++ -o test.exe main.o -L/Boost/stage/lib -llibboost_thread-vc100-mt
And that's where the trouble happens. First of all, If I didn't type the -l argument the way I did, MinGW couldn't even find the file. Meaning, if I tried:
-lboost_thread-vc100-mt
instead of the way I typed it above (and how I thought it should be done), ld would exit with no such file. Anyway, this is now the output I'm getting from that line:
main.o:main.cpp:(.text+0x47): undefined reference to `_imp___ZN5boost6thread4joinEv'
main.o:main.cpp:(.text+0x55): undefined reference to `_imp___ZN5boost6threadD1Ev'
main.o:main.cpp:(.text+0x70): undefined reference to `_imp___ZN5boost6threadD1Ev'
main.o:main.cpp:(.text$_ZN5boost6threadC1IPFvvEEET_NS_10disable_ifINS_14is_convertibleIRS4_NS_6detail13thread_move_tIS4_EEEEPNS0_5dummyEE4typeE[boost::thread::thread<void (*)()>(void (*)(), boost::disable_if<boost::is_convertible<void (*&)(), boost::detail::thread_move_t<void (*)()> >, boost::thread::dummy*>::type)]+0x23): undefined reference to `_imp___ZN5boost6thread12start_threadEv'
collect2: ld returned 1 exit status
Now somewhere in there, I can tell that these are apparently the functions I'm supposed to be getting from boost/thread, and apparently it does find the lib file, so why isn't it linking correctly?
Thank you very much for any help!
EDIT:
I've rebuilt boost using the bjam "stage" option
bjam toolset=gcc stage
Now, after the build completes, I'm left with a stage/lib folder with .a files, as is to be expected. These are the boost/thread related libraries:
libboost_thread-mgw45-mt-1_46_1.a
libboost_thread-mgw45-mt-d-1_46_1.a
However, linking as follows:
g++ -o test.exe main.o -L/Boost/stage/lib -lboost_thread-mgw45-mt-1_46_1
outputs the exact same errors. Also tried:
g++ -o test.exe main.o -L/Boost/stage/lib -lboost_thread-mgw45-mt-1_46_1 -static
I'm at a loss, still.
Solved the problem. Boost's headers are configured to be dynamically linked, but the dynamic libraries (dll's) are not built unless you specify:
--build-type=complete
when invoking bjam. After that, copy the appropriate dll to your application directory, but still use the
-L/BOOST_DIR/stage/lib -lname
when linking.
This set of library files:
libboost_thread-vc100-mt.lib
libboost_thread-vc100-mt-1_46_1.lib
libboost_thread-vc100-mt-gd.lib
libboost_thread-vc100-mt-gd-1_46_1.lib
are for the Visual Studio 2010 compiler. They won't work with GCC. If you want to use gcc/MinGW, you'll need to download/build a set of boost libraries for that compiler. Alternatively you can install VS 2010 and use that compiler (the free VC++ 2010 Express version should work fine if cost is an issue).
You can get a MinGW distribution with Boost already in the package from http://nuwen.net/mingw.html (32-bit target only, I believe).
To answer about getting the errors with using the MinGW libs:
The _imp_ prefixes on the symbols is an indication that g++ is looking to link to a a dll/shared library. The .lib file you have are for static libraries (which is what also what I get when doing a straightforward bjam build of the libraries). If you look in boost/thread/detail/config.hpp you'll see that for Win32 builds it defaults to building against a DLL library unless the MSVC or Intel compiler is being used.
I'm not even sure exactly how to build the DLL libraries - I'll have to look it up. In the meantime, you can use the following command to build your example such that it'll link against the static library. The BOOST_THREAD_USE_LIB macro build the .cpp file such that it'll expect to link against the static library:
g++ -I/Boost -DBOOST_THREAD_USE_LIB -c main.cpp
OS: Fedora 14
Compiler: g++ (GCC) 4.5.1 20100924 (Red Hat 4.5.1-4)
I installed gtkmm24-devel from repository via yum. To make sure the install went as planned I decided to try one of the examples on the page.
#include <gtkmm.h>
int main(int argc, char *argv[]) {
Gtk::Main kit(argc, argv);
Gtk::Window window;
Gtk::Main::run(window);
return 0;
}
I ran the example, and, hey! It said it couldn't find gtkmm.h, no problem, I just forgot to link the library. I added /usr/include/gtkmm-2.4 to my library search through Eclipse. No bueno, g++ still can't find it!
fatal error: gtkmm.h: No such file or directory
I then try to include gtkmm by using #include <gtkmm-2.4/gtkmm.h> and recompile, another error! :(
/usr/include/gtkmm-2.4/gtkmm.h:87:20: fatal error: glibmm.h: No such file or directory
Thanks for reading.
Short answer
Use the output of 'pkg-config gtkmm-2.4 --cflags' for include paths and 'pkg-config gtkmm-2.4 --libs' for libraries to link.
Long answer
It said it couldn't find gtkmm.h, no problem, I just forgot to link the library.
Building a C/C++ program is done in two separate steps. First the source files are compiled, outputting object files; and then the object files are linked together. The error you are getting comes from the compiling step.
On Linux, most libraries come with pkgconfig files to make it easier for other programs to use the libraries. gtkmm also comes with its own pkgconfig files.
You are trying to manually specify /usr/include/gtkmm-2.4 for include path; this is wrong. Instead, use the output of pkgconfig to figure out where the header files are located. To get all the include directories needed for gtkmm, use the following command:
pkg-config gtkmm-2.4 --cflags
For linking, use the following pkgconfig command to get the libraries you need to link with:
pkg-config gtkmm-2.4 --libs
You can test it on the command line by invoking g++ directly.
g++ myfirstprogram.cpp -o myfirstprogram `pkg-config gtkmm-2.4 --cflags --libs`
For more information, see the gtkmm docs: http://library.gnome.org/devel/gtkmm-tutorial/unstable/sec-basics-simple-example.html.en
These steps usually help resolving this problem:
Search your computer for glibmm.h
If found - add its directory to the include path list
If not found - Google for glibmm.h and find out which library it is contained in. You will find out in this case it's (surprise!) glibmm. Install it using your package manager.
The problem, as noted in comments, is a compiler error and the compiler is arguing about a missing (header) file. The steps I described above either find the location of the missing file or help you to install a library that the header file belongs to.
I'm trying to compile a program running on an HP UX server on a Red Hat Linux.
It uses xerces-c library to parse xml files. Compilation is ok, but when i try to run it, I get the following message
./a.out: error while loading shared
libraries: libxerces-c.so.28: cannot
open shared object file: No such file
or directory
I wrote a very simple program to try and understand whats going on:
#include <xercesc/util/PlatformUtils.hpp>
#include <xercesc/util/TransService.hpp>
#include <xercesc/parsers/SAXParser.hpp>
#include <xercesc/util/OutOfMemoryException.hpp>
int main(int argc, char* argv[])
{
return 0;
}
And compiled it like this:
g++ test.cpp
-L./xml/xerces-c_2_8_0/lib -lxerces-c -I./xml/xerces-c_2_8_0/include
Surprisingly the file is actually there:
lib]$ ls
libxerces-c.a libxerces-c.so.28 libxerces-depdom.a libxerces-depdom.so.28
libxerces-c.so libxerces-c.so.28.0 libxerces-depdom.so libxerces-depdom.so.28.0
Any thoughts ? I feel i'm missing something, but don't know what.
Thanks in advance.
run ldd a.out and see if the linker can resolve the right .so file
export LD_LIBRARY_PATH to include the current folder (in the same manner as the PATH variable) and check ldd again
the good way to do what you want is the following one:
g++ test.cpp -Xlinker -R ./xml/xerces-c_2_8_0/lib -lxerces-c -I./xml/xerces-c_2_8_0/include
or
g++ test.cpp -Wl,-rpath ./xml/xerces-c_2_8_0/lib -lxerces-c -I./xml/xerces-c_2_8_0/include
Xlinker or Wl options allow you to use specific linking options, you do not need to modifiy
LD_LIBRARY_PATH
You need to tell the runtime c library where to find the various symbols that arent compiled statically in your code and arent in the usualy /lib and /usr/lib locations.
You do this by adding the path to your shared library to LD_LIBRARY_PATH. In this case, this will be what you have been putting for the -L argument to the compiler.