Following the guide over at http://www.scratchapixel.com/lessons/3d-basic-lessons/lesson-2-get-started/get-started/ and I got down to the part where you set up GLFW. Everything was going fine got CMake all installed properly and it went through the process just as shown on the images on the site. Everything installed fine to the /usr/local/include and /usr/local/lib folders. So the next thing to do is test that it installed fine and every time I try to do anything with whats in the glfw folder, gives me this error:
fatal error: 'GLFW/glfw3.h' file not found
These are the commands I've tried to run it with:
gcc boing.c -o boing
gcc -lglfw boing.c -o boing
gcc -lglfw3 boing.c -o boing
gcc -I/usr/local/include boing.c -o boing (different error)
The last one almost worked and gave several different errors, which I think may have been caused by something else. That's kind of besides the point though. What am I doing wrong here? To my knowledge gcc is meant to look in the /usr/local/include folder by default for libraries.
Related
I have this strange issue where creating / using a static library works in my Ubuntu VM but not on macOS:
ld: warning: ignoring file ./dist/libXXXX.a, building for macOS-x86_64 but attempting to link with file built for macOS-x86_64
Command to create the static library is:
ar rcs libtest.a obj1.o obj2.o ...
Compiler invocation:
gcc -g -Wall -Wextra main.c -L./dist -lXXXX -o main
Searching on google didn't yield any usable results except for this (maybe) related question on SO:
Possible related question
I realize this is an old post and you found your fix, but let me post this here for anyone else who runs into this problem for whom these answers don't provide a solution.
You might be using two different toolchains unknowingly, one from Apple (installed via Xcode) and one from GNU (installed via Home-brew or MacPorts). If you type ranlib --version and see version info showing that ranlib is GNU, this is likely the case.
Make sure that /usr/bin comes in your $PATH before /usr/local/bin and /opt/local/bin. When you run which -a ranlib, the first result in the list should be /usr/bin/ranlib. Same for which -a ar-- the first result should be /usr/bin/ar. If it is not so, you need to fix your $PATH.
Once you fix your path and clean your project, try building again and things should work.
The issue was solved when I directly put those object files rather than gathering them into a static library, i.e.,
gcc -g -Wall -Wextra main.c obj1.o obj2.o -o main
After that, I got many warnings like ld: warning: object file (obj1.o) was built for newer macOS version (11.0) than being linked (10.14), but it is a warning, and the object is linked, so the problem is solved.
The root cause is that some library passes -mmacosx-version-min=10.14 to gcc, so the object file is built for 10.14, but my macos is now 11.0.
If you want to make things work, try directly using object files rather than creating a static library.
If you want to resolve all the warnings, find ``-mmacosx-version-min` and comment it.
After looking at my script that automatically creates the static library I've found the culprit:
For some reason my tool created object files for header files (resulting in files like header.h.o).
Removing those fixed the issue.
I am trying to open my in-built camera in order to make a Face Detection program, but I notice that VideoCapture.open(0) does not work when I attempt to run through a cmake compilation, but DOES work when I compile and run through g++.
This program is part of a project, and compiling through CMake is necessary, but nothing seems to work...
(I'm using Ubuntu)
My code compiles and runs, opening the in-built camera (returning "true" on if(capture.isOpened())), when I use
g++ main.cpp FaceDetection.cpp `pkg-config --cflags --libs opencv4`
but returns false on if(capture.isOpened()) and does not open the in-built camera when I compile through cmake.
Any ideas on what I should do for this to run like it runs when I compile it with g++?
Edit: Removed my code, as it wasn't a problem with the code at all. Will answer my own question as I found a solution.
Ran make VERBOSE=1, cmake ../ --log-level=VERBOSE, and
g++ main.cpp FaceDetection.cpp `pkg-config --cflags --libs opencv4`
as Tsyvarev suggested, and found that g++ was including opencv from /usr/include while cmake was including opencv from /usr/local
I found this SOLUTION:
Ran cd /opt/opencv/build && make uninstall first and then ran make in my project folder, which actually solved the problem and opened the camera.
I'm not sure what caused this, but if this happens to anyone, hope this helps!
I am trying to compile a program which uses GSL, in fact I am already able to compile it successfully on my local machine using
g++ -o program program.c prog0.o -L/usr/local/lib -lgsl -lgslcblas -lm
My problem is that I need to compile this program on a work machine in a shared system, but I know the program will not compile with an up to date version of GSL, so I need to install and use an older version.
I did this on my own system using the default installation, so the relevant files are located in /usr/local/lib on my local machine, and the compilation works for me with the above command.
But since the work machine is in a shared system, I cannot mess with the default directories, so I installed the correct GSL version on the work machine in my directory under /home/myname/gsl/.
So on the work machine the folder /home/myname/gsl/lib contains the same relevant files as the folder /usr/local/lib on my machine.
Now I did various attempts to try and tell g++ to use this custom installation folder, which I thought would come down to
g++ -o program program.c prog0.o -L/home/myname/gsl/lib -lgsl -lgslcblas -lm
but no success. No matter what I did g++ always used the GSL version installed on the shared system, even using just
g++ -o program program.c prog0.o
I only started programming C/C++ not long ago and only know the very basics of how to compile programs, so this linking thing is still always confusing me..
But as far as I can tell -L/dir/ should tell g++ to use the library in /dir/ and -lgsl -lgslcblas are the files which it should look for in that library... ?
But it seems g++ doesn't care what library I tell it here, it always seems to use whatever is in the PATH of the shared work system, which seems to include this up-to-date version of GSL that I cannot use. But I also cannot change the PATH since I only have access to my own subdirectories on the work system..
So how do I tell g++ to ignore the default version of GSL and use the one I installed manually at /home/myname/gsl/ ?
I figured out the answer, it is actually simple. The problem was just my lack of understanding proper usage of outside libraries and trying to fix the compilation command was the wrong approach.
In the code in program.c, gsl was included with
#include <gsl/gsl_blas.h>
and so on. Of course, the "<>" directly tell the compiler to look in known include directories, where the up-to-date GSL is installed on the shared system.. So the way to use a custom version was just to instead use
#include "/home/myname/gsl/lib/gsl_blas.h"
and so on, directly specifying that I want to use my custom installation.
I then compiled with
g++ -o program program.c prog0.o /home/myname/gsl/lib/libgsl.so /home/myname/gsl/lib/libgslcblas.so -lm
and it compiles successfully.
(This brought up some other unclarities for me, but at least this specific problem is solved.)
I am attempting to build an application using g++ that is composed of several source files and also uses OpenCV 3.1.0.
The CMD command is:
g++ -o home_surveillance -static -std=c++11 -m64 -IC:\Tools\OpenCV\opencv\build\include -LC:\Tools\OpenCV\opencv\build\x64\vc14\lib -lopencv_world310 configuration_manager.cpp events.cpp image_processor.cpp main.cpp response_module.cpp scheduler.cpp
The error produced is:
C:/Program Files/mingw-w64/x86_64-6.2.0-posix-seh-rt_v5-rev1/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/6.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot find -lopencv_world310
collect2.exe: error: ld returned 1 exit status
I have been trying various things and searching for answers for a couple days now. I should note that the application builds properly in Visual Studio 2015. I have tried compiling the source files using g++ with the -c option and they all seem to compile fine. It is just the linking phase that produces an error.
Things I have tried:
Just about every possible combination of the specified command. (Modifying order of the options, -lopencv_world310.a, -lopencv_world310.lib, -lopencv_world310, -l"full_path"+"opencv_world310", etc..)
Checked that all the paths and filenames are correct.
Reinstalled mingw to make sure I was using mingw-w64 since this is a 64-bit application.
Running CMD as admin thinking maybe CMD could not access the path specified with -L option.
Googling and reading every post I could find. (Most posts about "ld.exe cannot find "library_name" are a result of someone using "library_name".a or "library_name".lib as input to the -l option).
Reading mingw documentation on the use of GCC/g++ to ensure I wasn't missing anything obvious.
Praying to Bjarne Stroustrup.
Ritual sacrifice involving a Pentium 2.
Just recently I tried to install GTK+ on Windows 7 using all-in-one bundle and latest MinGW package. I proceeded with all steps of official tutorial. Lurking through several tutorials, especially this one helped me getting MinGW and MSYS set up, so GCC sure works. The command
pkg-config --cflags --libs gtk+-3.0
printed out the expected set of paths/options. However, when I tried to run either
gcc -o gtk3.exe gtk3.c (pasted 'pkg-config' output)
or
gcc -o gtk3.exe gtk3.c `pkg-config --cflags --libs gtk+-3.0`
I've got
gcc: error: gtk3.c: No such file or directory
as a result. Searching the file manually was no success as well. It seems that Windows command prompt has torn the original long command apart, but I don't think that it would be this way if GCC has initialized gtk3.c.
I believe that official tutorial can't be wrong, so please help me resolve this problem.
Best regards, Mathias.
A Windows installation tutorial for GTK+ might not be the most thoroughly tested thing... This is a better version of that page, it includes a link to the source file (although any GTK+ "hello world" code will do).
You could file a bug on the missing link and images as well if you want to help others.