I want to set up GLFW3 to work with C++ in a program called 4coder. I have a folder named libraries that holds all the stuff I need, I just don't know how to get C++ to include them using #include <GLFW/glfw3.h>. I literally started using C++ today and have no idea where to start.
You will need to add arguments when compiling the source code to specify the location of your headers and libraries. Exactly how this is done will depend on which compiler you are using but for example if you're using g++:
path-to-working directory>g++ name-of-file.cpp -Ipath-to-header-files -Lpath-to-library-files -lglfw3 -o name-of-executable
The key points here are the -I flag (which tells the compiler where to look for header files) and the -L flag (which tells the compiler where to look for libraries). -lglfw3 will then cause the compiler to look in the directory specified with the -L flag for the glfw3 library.
If you're using a different compiler, the syntax may be different but the general principle will apply - you just have to find the equivalent commands to -I and -L.
Related
I have 'correctly' installed gsl on mac 10.13.2.
In my c++ program, I am calling like usual, for example:
#include <gsl/gsl_math.h>
However while running the code, it can not find the gsl.
fatal error: 'gsl/gsl_math.h' file not found
I was wondering how to correctly link gsl PATH and libraries.
I have tried,
setting PATH and LD_LIBRARY_PATH in .bash_profile
setting PKG_CONFIG_PATH to .../Gsl2.3/lib/pkgconfig
$which gsl-config returns
/Users/gkdgoutam/Softwares/HEP_Softwares/Install/Gsl2.3/bin/gsl-config
$pkg-config --libs gsl returns
-L/Users/gkdgoutam/Softwares/HEP_Softwares/Install/Gsl2.3/lib -lgsl -lgslcblas -lm
The only solution I can find is to run everytime with gsl linked.
Like:
g++ $(gsl-config --cflags) mycode.cc $(gsl-config --libs) && ./a.out
But I was wondering if the GSL PATH can be set globally so that I can simply run
g++ mycode.cc && ./a.out
This is how c++ code is compiled and built:
COMPILATION
A compilation unit will take each cpp file and work its way through included headers to locate forward declaration of implementations of symbol signatures of used functionality in your code. In your case this involves gsl/gsl.h. If the file cannot be found in the search directories, which you can expand by specifying C_INCLUDE_PATH and or CPLUS_INCLUDE_PATH. If you omit #include <gsl/gsl_math.h>, your code will not compile as there are signatures, which cannot be found for GSL functions, which you use.
LINKING
Once you have compiled all cpp/cc files you need to link the binary, which can be executed. The linking process consists of a search through all symbols in your .o/.obj... files and a matching of the same to what it can find in your object files and the libraries, which you have specified using for example -lgsl. If all goes well, every lookup finds an according binary implementation for your machine's hardware model (i.e. 64bit/32bit ..., Arm, Intel, ... etc). If some are not found you will find linkage errors.
What you are asking is, is there a way that C++ does not work as above? No!
If you leave out #include <gsl/gsl.h> or if said file is not found in your search paths, compilation will not work or. If you omit -lgsl, linking will fail. If you find it annoying to write all the above stuff in the command line, write a Makefile to reduce the building process to ideally a simple command: make.
Don't forget, that if you are linking against the shared library version of GSL, you might need specifying LD_LIBARAY_PATH on Linux and DYLD_LIBRARY_PATH on Macs as well.
TLDR: you cannot ask a c++ compiler / linker to work differently as designed.
I downloaded the FMUSDK and I want to compile the code. Unfortunately the build script is supposed to work with the Visual Studio C compiler, but I can't install/use it on my machine. Thus, I try to modify the script (and some parts of the code) to be able to compile it with the GCC. But I am completely new to compiling complex code (I usually just use gcc *.c -o outfile.exe)
Here is my problem:
In some files there is a library linked with
#pragma comment(lib, "libxml2.lib")
This does not work with GCC.
The lib can be found in ..\shared\parser\libxml2.lib
with headers files in ..\shared\parser\libxml\
I call the build script with
fmusdk\fmu20\src\co_simulation>..\build_fmusim_cs_gcc.bat
The script then looks like this:
set SRC=main.c ..\shared\sim_support.c ..\shared\xmlVersionParser.c ..\shared\parser\XmlParser.cpp ..\shared\parser\XmlElement.cpp ..\shared\parser\XmlParserCApi.cpp
set INC=-I ..\shared\include -I ..\shared -I ..\shared\parser\libxml -I ..\shared\parser
set LIB=-L ..\shared\include -L ..\shared -L ..\shared\parser\libxml -L ..\shared\parser
set OPTIONS=-D FMI_COSIMULATION -D STANDALONE_XML_PARSER -D LIBXML_STATIC -v
g++ %INC% %OPTIONS% %SRC% %LIB% -lxml2 -o fmu20sim_cs.exe
But I get the following error message:
c:/users/<username>/userprograms/mingw/bin/../lib/gcc/mingw32/6.3.0/../../../../mingw32/bin/ld.exe: cannot find -lxml2
I tried to use what I found on http://www.rapidtables.com/code/linux/gcc/gcc-l.htm, but I seems not to work.
Can someone help? What am I doing wrong? Under INC and LIB I put everything that looked helpful, but I have no idea what I am really doing there ...
I have also a logfile with the verbose output of the batch file. But I don't see how to upload it here :(
Best regards,
Martin
libxml2.lib is the example of (quite frequent) messing with library name conventions. Visual Studio uses the convention of adding .lib extension (this would be xml2.lib), GCC uses the convention of adding lib prefix and .a extension to library name (this would be libxml2.a).
According to GCC manual (https://gcc.gnu.org/onlinedocs/gcc-7.2.0/gcc/Link-Options.html#Link-Options) you have two options:
Change the library file name to the libxml2.a, because that is the file name GCC is looking for when given the -lxml2 option.
The linker searches a standard list of directories for the library, which is actually a file named liblibrary.a.
Provide the full name of the library file , without -l (e.g. change -lxml2 to libxml2.lib in g++ command line), then the GCC will look for the given name exactly.
A file name that does not end in a special recognized suffix is considered to name an object file or library. (Object files are distinguished from libraries by the linker according to the file contents.) If linking is done, these object files are used as input to the linker.
You should replace -lxml2 by -llibxml2.
Explaination, from Mingw :
Also note that the library names "lib<name>.a" and "lib<name>.lib" are not equivalent; if you have a library named according to the aberrant "lib<name>.lib" convention, it will not be found by an "-l<name>" specification -- if you cannot rename the library, you must use the form "-llib<name>" instead.
How do I include glfw.h and link the libraries libglfw.a and libglfadll.a in eclipse juno c++ with MinGW compiler. This is an attempt I made on setting it up:
This is the build command I tried to use:
g++ -o Practice.exe "src\\main.o" "-lC:\\Users\\Kaiden.ZEUS\\Files" & "Folders\\Programming\\C++\\Workspaces\\Practice\\Practice\\lib\\libglfw.a" "-lC:\\Users\\Kaiden.ZEUS\\Files" & "Folders\\Programming\\C++\\Workspaces\\Practice\\Practice\\lib\\libglfwdll.a"
Nothing of this is specific to OpenGL or GLEW, you're dealing with basic programmer craftsmanship skills here: How to configure a compiler linker toolchain to use additional libraries. This is essential knowledge, so please take the patience to properly learn it. The following is just a short list of notes what you should change. But you should really take up some learning material on the compilation and linking process to understand it.
You should place the libraries and headers into system wide directories, but not the standard directories of the compiler suite and configure those as additional search paths for the compiler and linker.
DO NOT put 3rd party library and header files into your project source tree, unless you take proper precautions that it won't interfere with likely installed systemwide instances of them.
Also you must choose between the static or the dynamically linked version of GLFW. If you use both you'll get symbol conflicts (this is something specific to GLFW).
In your build command line you're using the -loption with *directories*. This is wrong, search paths are specified using-L(capital L), while-l(lower l) just specifies library names without the path, prefix and suffix. Also you can replace backslashes` with forward slashes /, saving you some typing, i.e. the \\ escaping to produce a single backslashe to the command. In your case (I shortened the path)
g++ -o Practice.exe "src/main.o" "-LC:/Users/Kaiden.ZEUS/Files/ ... /lib" "-lglfw"
or
g++ -o Practice.exe "src/main.o" "-LC:/Users/Kaiden.ZEUS/Files/ ... /lib" "-lglfwdll"
However this compile command lacks specification of the include files. Say you've got the GLEW headers installed in C:/Users/Kaiden.ZEUS/Files/ ... /include/GL you'd add
"-IC:/Users/Kaiden.ZEUS/Files/ ... /include/GL"
to the command line.
This problem is not specific to Fubi, but a general linker issue. These past few days (read as 5) have been full of linking errors, but I've managed to narrow it down to just a handful.
I'm trying to compile Fubi (Full Body Interaction framework) under the Linux environment. It has only been tested on Windows 7, and the web is lacking resources for compiling on a *nix platform.
Now, like I mentioned above, I had a plethora of linking problems that dealt mostly with incorrect g++ flags. Fubi requires OpenNI and NITE ( as well as OpenCV, if you want ) in order to provide it's basic functionality. I've been able to successfully compile both samples from the OpenNI and NITE frameworks.
As far as I understand, Fubi is a framework, thus I would need to compile a shared library and not a binary file.
When I try to compile it as a binary file using the following command
g++ *.cpp -lglut -lGL -lGLU -lOpenNI -lXnVNite_1_5_2 -I/usr/include/nite -I/usr/include/ni -I/usr/include/GL -I./GestureRecognizer/ -o FubiBin
and I get the output located here. (It's kind of long and I did not want to ruin the format)
If I instead compile into object files (-c flag), no errors appear and it builds the object files successfully. Note, I'm using the following command:
g++ -c *.cpp -lglut -lGL -lGLU -lOpenNI -lXnVNite_1_5_2 -I/usr/include/nite -I/usr/include/ni -I/usr/include/GL -I./GestureRecognizer/
I then am able to use the ar command to generate a statically linked library. No error [probably] occurs (this is only a guess on my end) because it has not run through the linker yet, so those errors won't appear.
Thanks for being patient and reading all of that. Finally, question time:
1) Is the first error regarding the undefined reference to main normal when trying to compile to a binary file? I searched all of the files within that folder and not a single main function exists.
2) The rest of the undefined reference errors complain that they cannot find the functions mentioned. All of these functions are located in .cpp and .h files in the subdirectory GestureRecognizer/ which is a subdirectory of the path I'm compiling in. So wouldn't the parameter -I./GestureRecognizer/ take care of this issue?
I want to be sure that when I do create the shared library that I won't have any linking issues during run-time. Would all of these errors disappear when trying to compile to a binary file if they were initially linked properly?
You are telling the compiler to create an executable in the first invocation and an executable needs a main() function, which it can't find. So no, the error is not normal. In order to create a shared library, use GCC's "-shared" option for that. Trying some test code here, on my system it also wants "-fPIC" when compiling, but that might differ. Best idea is to dissect the compiler and linker command lines of a few other libraries that build correctly on your system.
In order to add the missing symbols from the subdirs, you have to compile those, too: g++ *.cpp ./GestureRecognizer/*.cpp .... The "-I..." only tells the compiler where to search when it finds an #include .... I wouldn't be surprised if this wasn't even necessary, many projects use #include "GestureRecognizer/Foo.h" to achieve that directly.
BTW:
Consider activating warnings when running the compiler ("-W...").
You can split between compiling ("-c") and linking. In both cases, use "g++" though. This should decrease your turnaround time when testing different linker settings.
I'm adding two classes and libraries to a system, parent.so and child.so deriving from it.
The problem is when the program is loading child.so it cannot find parent's virtual function's definition from parent.so.
What happens,
nm -D child.so will gives something like (I just changed the names)
U _ZN12PARENT15virtualFunctionEv
The program will crash running
_handle = dlopen(filename, RTLD_NOW|RTLD_GLOBAL); //filename is child.so
it'll give an error with LD_DEBUG = libs
symbol lookup error: undefined symbol: _ZN12PARENT15virtualFunctionEv (fatal)
The thing I cannot explain is, I tried LD_DEBUG = symbols using GDB, when running dlopen, the log shows it tried to look up basically in all libaries in the system except parent.so, where the symbol is defined. But from libs log parent.so is already loaded and code is run, and it is at the same path of all other libraries.
......
27510: symbol=_ZN12PARENT15virtualFunctionEv; lookup in file=/lib/tls/libm.so.6
27510: symbol=_ZN12PARENT15virtualFunctionEv; lookup in file=/lib/tls/libc.so.6
27510: symbol=_ZN12PARENT15virtualFunctionEv; lookup in file=/lib/ld-linux.so.2
27510: child.so: error: symbol lookup error: undefined symbol: _ZN12PARENT15virtualFunctionEv(fatal)
How the program or system is managing which library to look for a symbol's definition?
I'm new to Linux, can anybody point me some directions to work on?
Thanks.
EDIT
The command used to generate parent.so file is
c++ -shared -o parent.so parent.o
Similar for child.so. Is any information missing for linking here? Looks like child is only including parent's header file.
EDIT2
After another test, calling
_handle = dlopen("parent.so", RTLD_NOW|RTLD_GLOBAL);
before the crashing line will solve the problem, which I think means originally parent.so was not loaded. But I'm still not very clear about the cause.
You need to tell the linker that your library libchild.so uses functionality in libparent.so. You do this when you are creating the child library:
g++ -shared -o libchild.so child_file1.o child_file2.o -Lparent_directory -lparent
Note that order is important. Specify the -lparent after all of your object files. You might also need to pass additional options to the linker via the -Wl option to g++.
That still might not be good enough. You might need to add the library that contains libparent.so to the LD_LIBRARY_PATH environment variable.
A couple of gotchas: If you aren't naming those libraries with a lib prefix you will confuse the linker big time. If you aren't compiling your source files with either -fPIC or -fpic you will not have relocatable objects.
Addendum
There's a big potential problem with libraries that depend on other libraries. Suppose you use version 1.5 of the parent package when your compile your child library source files. You manage to get past all of the library dependencies problems. You've specified that your libchild.so depends on libparent.so. Your stuff just works. That is until version 2.0 of the parent package comes out. Now your stuff breaks everywhere it's used, and you haven't changed one line of code.
The way to overcome this problem is to specify at the time you build your child library that the resultant shared library depends specifically on version 1.5 of libparent.so`.
To do this you will need to pass options from g++/gcc to the linker via the -Wl option. Use -Wl,<linker_option>,<linker_option>,... If those linker options need spaces you'll need to backslash-escape them in the command to g++. A couple of key options are -rpath and -soname. For example, -rpath=/path/to/lib,-soname=libparent.so.1.5.
Note very well: You need to use the -soname=libparent.so.1.5 option when you are building libparent.so. This is what lets the system denote that your libchild.so (version 1.0) depends on libparent.so (version 1.5). And you don't build libparent.so. You build libparent.so.1.5. What about libparent.so? That needs to exist to, but it should be a symbolic link to some numbered numbered version (preferably the most recent version) of libparent.so.
Now suppose non-backward compatible parent version 2.0 is compiled and built into a shiny new libparent.so.2.0 and libparent.so is symbolically linked to this shiny new version. An application that uses your clunky old libchild.so (version 1.0) will happily use the clunky old version of libparent.so instead of the shiny new one that breaks everything.
It looks like you're not telling the linker that child.so needs parent.so, use something like the following:
g++ -shared -o libparent.so parent.o
g++ -shared -o libchild.so -lparent child.o
When you build your main program, you have to tell the compiler that it links with those libraries; that way, when it starts, linux will load them for it.
Change their names to libparent.so and libchild.so.
Then compile with something like this:
g++ <your files and flags> -L<folder where the .so's are> -lparent -lchild
EDIT:
Maybe it would be a smaller change to try loading parent.so before child.so. Did you try that already?