UPDATE
I've sorted this by explicitly adding the appropriate -I and -L options, but I'm curious as to why this is necessary now when it wasn't before? On the plus side those annoying library out-of-sync warnings are gone.
UPDATE ENDS
I've broken my OSX OpenGL build environment. I'm building from terminal (using make) with g++, for example:
g++ -o myprog main.o -lglfw -lglew -framework OpenGL
and getting errors:
ld: library not found for -lglfw clang: error: linker command failed with exit code 1 (use -v to see invocation)
These are in addition to compiler errors such as:
g++ -c main.cpp main.cpp:3:10: fatal error: 'GL/glew.h' file not found
So it seems the OpenGL libraries and includes have been lost. Everything was working fine until I executed the command:
export SDKROOT="$(xcode-select -p)/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk"
Which I did to try and fix warning messages like:
ld: warning: text-based stub file /System/Library/Frameworks//OpenGL.framework/OpenGL.tbd and library file /System/Library/Frameworks//OpenGL.framework/OpenGL are out of sync. Falling back to library file for linking.
I got that 'fix' from here: macOS framework lib problem
I realise it was reckless running commands that I don't fully understand but nonetheless... now I can't compile/link any OpenGL code and after scouring the internet for help I've come up with nothing, so here I am.
I'm running OSX 10.13.6 on a 2013 MacBook Pro.
First post BTW so please forgive me if I've not provided enough detail.
Related
I know it's going to be a silly mistake, and I'm aware that there are similar posts however none have helped so far, so I'm resorting to a new post.
I'm trying to compile the simplest GLFW hello world example.
In my project directory (I'm using vscode) there is a main.cpp file, and the glfw lib file I downloaded from glfw.org which I renamed to libglfw3.a (It's precompiled) I am using a MacBook Air M1.
I'm trying to compile it with this command:
clang -I /opt/homebrew/Cellar/glfw/3.3.7/include -L /Users//projects/ -l libglfw3.a main.cpp -o helloglfw
The output I get is:
ld: library not found for -llibglfw3.a
clang: error: linker command failed with exit code 1 (use -v to see invocation)
I'm clearly dumb because for the life of me I can't see what I'm doing wrong...
Things I've tried:
linking to the homebrew version of glfw which contains a .dylib of glfw
tried linking libglfw3 (without the .a extension)
compiling to an object file and then linking with ld separately
using g++
Not using the -L flag and just pasting the full path into -l
Praying and restarting the pc just in case.
Waiting for it to fix itself
Some assistance would be appreciated.
OK SO! I fixed it. Apparently it works if there is NO SPACE between the -L and -l parameters.
so the command looks like this:
clang <source files> -I<Include Paths> -L<pathtolibs>-l<libs>
No clue why, but whatever I'm done...
Basic Info:
system: macOS High Sierra(10.13.6)
editor : vs code(latest version)
Compiler: g++ (Xcode)
Target：deploy GLFW + GLAD
Question Description:
Recently, I'm learning to do some Computer Graphics related work. Everything is going smooth. However, when i create a window to test the env.Link error happened:
Undefined symbols for architecture x86_64:
"_gladLoadGLLoader", referenced from:
_main in main-5c211c.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
The terminal process terminated with exit code: 1
It seems I have not link some third party file. I
have fixed exactly the same problem by add "-lglfw" args to g++ when using functions in glfw3.h.
But when meeting glad related function : gladLoadGLLoader, I don't know how to do.
Something I have done:
Can find the head file.
#include glad/glad.h
#include GLFW/glfw3.h
Have put the file "glad.c" in workspace.
Try to Add "g++ -framework XXXXX" , But doesn't work.
Try to Add "g++ -lglfw3", But doesn't work.
Add "g++ -L or I /usr/lib or /usr/local/lib or /usr/local/include", But doesn't work.
Just tell the g++ to compile glad.c by adding "glad.c" to args. I thought glad.c will be compiled by default. Although I am not clear what happened, the problem is resolved anyway.
Add glad.c into Build Phases->Compile Sources
I am trying to build SDL for use with Eclipse. I am trying to remove this linker error:
Beginning Compilation
21:15:53 **** Incremental Build of configuration Debug for project CMD ****
Info: Internal Builder is used for build
g++ "-IC:\\MinGW\\include\\SDL2" -O0 -g3 -Wall -c -fmessage-length=0 -o "src\\CMD.o" "..\\src\\CMD.cpp"
g++ -o CMD.exe "src\\CMD.o" -lmingw32 -lSDL -lSDL2main -lSDL2
ERROR(s):
c:/mingw/bin/../lib/gcc/mingw32/5.3.0/../../../../mingw32/bin/ld.exe: cannot find -lSDL
collect2.exe: error: ld returned 1 exit status
21:15:54 Build Finished (took 1s.36ms)
The most pertinent SO archive source I researched didn't seem to have an actionable answer for my problem, though it had the exact same problem/error:
title --
producing the same error message:
c:/mingw/bin/../lib/gcc/mingw32/4.7.0/../../../../mingw32/bin/ld.exe: cannot find -lSDL.
If you click to the authors "solution" for the same error as mine its not clear to me how he solved it.
Any help?
Problem solved, SDL2 awesome. Ok:
c:/mingw/bin/../lib/gcc/mingw32/4.7.0/../../../../mingw32/bin/ld.exe: cannot find -lSDL.
Reinstallation of SDL2 avoiding binary conflict between SDL files and SDL2 files
as keltar mentioned resolved the immediate problem, and the problem built with no errors!Fixing what was in the braces unmasked new problem: crashing. I stripped the program to bare bones and concluded the crashing was outside of the code since it was occurring even without code.
To solve the new problem would need to go the SDL2 distribution file (the one copied to MinGW) and copy the SDL2.dll from it [DLL from distributable][1]--- by dragging the file over your debug and/or release folders where the .exe file lives.(.exe + dll -> right?) moving dll to exes. Build/Run the program
it should work!
You should see a Welcome message!
https://www.caveofprogramming.com/c-for-complete-beginners/setting-up-sdl-windows.html
This is my first question on stackoverflow. I've seen a few posts related to openGL on Ubuntu, but none seem to relate to the problem I'm having.
For some reason whenever I try to build my project in eclipse-CDT I get the following console output:
**** Build of configuration Debug for project windows ****
make all
Building file: ../src/windows.cpp
Invoking: GCC C++ Compiler
g++ -O0 -g3 -Wall -c -fmessage-length=0 -MMD -MP -MF"src/windows.d" -MT"src/windows.d" -o "src/windows.o" "../src/windows.cpp"
Finished building: ../src/windows.cpp
Building target: windows
Invoking: GCC C++ Linker
g++ -o "windows" ./src/OGdisplay.o ./src/windows.o -lGLEW -lGL -lSDL2
/usr/bin/ld: cannot find -lGL
collect2: error: ld returned 1 exit status
makefile:45: recipe for target 'windows' failed
make: *** [windows] Error 1
**** Build Finished ****
I've installed the mesa-common-Dev package and all the others I could find that have to do with opengl development, but it won't budge. I put: GLEW, GL, and SDL2 in libraries under the GCC C++ linker settings. It doesn't seem to have any issues finding SDL2 and GLEW, but for some reason just can't find GL.
I went to usr/include and can clearly see the GL folder with it's contents as well as SDL2(which it has no issues finding). I've tried the same thing in codeblocks with extremely simple code and get the same result saying it can't find GL.
I'm running Ubuntu 16.04LTS with an nvidia GeForce GTX 1060. I'm also using the NVIDIA Xserver driver version 367.44. Under the nvidia Xserver settings in the OpenGL information sections it says it has version: 4.5.0 NVIDIA 367.44 if that helps. If you need anymore information just let me know, I'm almost certain that it's something simple I'm not thinking of.
Here are my CDT linker settings if it'll let me post a pick:
linker settings screenshot
SOLUTION: I'm not sure it's much of a solution, but I reinstalled NVIDIA X server and it seems to be working fine now. Not sure what was orginally causing it though.
On OSX 10.6.4 with i686-apple-darwin10-g++-4.2.1 compiling using TextMate and a Makefile which in the first place has been made für a Linux and I am trying to translate for OSX.
When compiling a c++ project I get the "can't link with a main executable" error:
g++ -Wall -g -I ~/svnX-Repository/axp-Projekte/xrlfupa/trunk/src/ -I ~/svnX-Repository/boost_1_44_0 -I /opt/local/var/macports/software/boost/1.44.0_0/opt/local/lib/ -I /opt/local/var/macports/software/gsl/1.14_0/opt/local/include/ -o xrfLibTest xrfLibTest.o excitFunctions.o xrfFunctions.o filterFunctions.o detectorFunctions.o -L/opt/local/var/macports/software/boost/1.44.0_0/opt/local/lib/ -L/opt/local/var/macports/software/gsl/1.14_0/opt/local/lib/ -lm -lxrlTUB -lboost_serialization -lgsl -lgslcblas # Debug 1
ld: in /usr/local/lib/libxrlTUB.so, can't link with a main executable
collect2: ld returned 1 exit status
make: *** [prog] Error 1
The library that is mentioned (libxrlTUB.so) is in its place (/usr/local/lib/libxrlTUB.so) but, possibly that is where the problem came from, the libxrlTUB.so has been compiled by myself beforehand as well.
The compile process went through, it was generated by swig, though there was a warning:
g++ -arch x86_64 -m32 -g -fpic -I /usr/include/python2.6 -c PyXrl_wrap.cxx
In function 'void SWIG_Python_AddErrorMsg(const char*)':
warning: format not a string literal and no format arguments
which, as far as I could find out, shouldnt be a problem. (Or is it?)
Unfortunately this whole thing is part of a project from the university. Actually I am supposed to write an X-ray-analysis script in python, which would be fine, if... well if I wouldn't be expected to use the librarys that are meant to result from this c++ project.
(Afterwards they should be used via import in python.)
I am not really experienced with c++, neither with compiling on OSX systems. So far I have been bothering with scipting (python, bash, etc). So Maybe I am just missing something simple. Hopefully someone can give me an hint where I can continue reading in order to deal with the above "can't link with a main executable" error...
Thanx in advance,
Liam
The error message is telling you the problem—it is that /usr/local/lib/libxrlTUB.so is not a shared library; it's an executable. You can't link against an executable. Probably whatever build process you used for libxrlTUB.so didn't understand how to build shared libraries on the Mac (it's more suspect because .dylib is the correct extension to use.)
Take a look at Apple's documentation on compiling dynamic libraries. You can use file to make sure your output is of the correct type, for example:
% gcc -c foo.c
% gcc -dynamiclib foo.o -o foo.dylib
% file foo.dylib
foo.dylib: Mach-O 64-bit dynamically linked shared library x86_64
Without -dynamiclib you end up with an executable, which may be the problem you've run into.