OpenGL setup for code::blocks "cannot find -lXxf86vm" - opengl

I'm working on setting up a dev environment for school. We're going to be using GLUT to do graphics programming. I installed freeglut on Ubuntu using
sudo apt-get install freeglut3-dev
I am going to be using code::blocks to write everything (as per the instructor's specifications) but when I try to build the default GLUT project in code::blocks, I get the following
Compiling: main.cpp
Linking console executable: bin/Debug/glut_test
/usr/bin/ld: cannot find -lXxf86vm
collect2: ld returned 1 exit status
It looks to me like I'm missing some dependency, but I can't for the life of me figure out what it is. I have no idea what -lXxf86vm is, nor does Google or any other forum I can find.
Does anyone have ideas?
Update 1) this may have something to do with the fact that I have an Nvidia Optimus card in this laptop.
I tried running the default OpenGL project as well and it's throwing the following error
main: X server has no OpenGL GLX extension
I'm going to try installing bumblebee and see if that gets me anywhere

I have no idea what -lXxf86vm is, nor does Google or any other forum I can find.
This library provides an API for the XF86VidModeSwitch extension. XF86VidMode has been superseeded by XRandR, but freeglut may need it for its game mode support.
Just install the package "libxxf86vm-dev",
Update 1) this may have something to do with the fact that I have an Nvidia Optimus card in this laptop.
No, that's not the reason for this particular library to be missing
I tried running the default OpenGL project as well and it's throwing the following error
Well, you have not installed the NVidia-Drivers correctly.

CodeBlocks always adds "Xxf86vm" to new GLUT projects.
I have no idea what it is, or why CodeBlocks adds it, (very annoying bug?) but you almost definitely DONT NEED IT!.
You can find it under: Project -> Build options... -> Linker settings.
Select your project name in the left pane, and it should appear under: "Link libraries".
Now, Just delete it from the list. Your code should compile and run fine without it.

Related

MySql connector-c++ wont link in QtCreator but works fine locally on raspberry pi3

Firstly, thank you in advance for at least reading this question.
Secondly, feel free to call me an idiot if this is a "no brainer"
Now down to the issue at hand...
I am running Ubuntu 16.04 (64bit) with QT Creator as my IDE and on the whole it works great. I can cross compile for the Raspberry Pi3 (running raspbian) and also compile plugins for X-Plane.
Everything was going great until I needed to implement MySql into my project. That's when it all went south.
I can not use the Qt library for this as X-Plane does not like anything Qt related in its plugins. But that is fine, I have connector-c++ working on that machine and it connects to my MySql server and does everything it's supposed to.
I think I have read just about every forum and watched every youtube video on this but can not get Qt Creator to compile with connector for the raspberry pi.
I wrote/compiled a test app locally (with g++) on the pi and it works great. However for some reason (government plot maybe?) it refuses to link the libraries when compiling under Qt Creator.
The error I get when compiling in QtCreator is:
undefined reference to `get_driver_instance'
Currently,
I have followed the instructions for setting up a cross compiler here:
https://wiki.qt.io/RaspberryPi2EGLFS
Downloaded the connector code from here:
git clone https://github.com/mysql/mysql-connector-cpp
I have followed the instructions for compiling connector-c++ here:
https://dev.mysql.com/doc/connector-cpp/en/connector-cpp-installation-source-unix.html
And I have banged my head 1000x on a brick wall here:
(picture of blood stained wall not available)
Also, I have tried compiling connector on my Ubuntu pc with paths to the pi's sysroot etc. but i think it made a 64bit version which causes Qt Creator to have a dummy spit about "unrecognized format".
I am hoping that this is just me having a "senior moment" and that someone can point me in the right direction.
To save putting up irrelevant logs/code I will wait until someone asks for it and then copy/paste what they need.
Again, thanks in advance and know that I will be eternally grateful for any light on this matter (preferably before I go even insanerer)
Well after 2 weeks of pain, I have solved this problem. Here is what I think is the issue:
Firstly, I found that mysqlcppconn is not needed (at least for me) and used the mysql libraries in /usr/lib
Secondly, the symlinks to libmysqlclient.so.6.0.22 were by default:
libmysqlclient.so.6 -> libmysqlclient.so.6.0.22
The compiler was looking for libmysqlclient.so which didn't exist. So I created the link (libmysqlclient.so -> libmysqlclient.so.6) and it worked!!
Thanks to all who helped.

Building glfw3 programs in CodeBlocks 16.01 in Windows 7 failed

I am using CodeBlocks 16.01 in Windows7. I have downloaded GLFW windows binary from here. I have copied include and lib-mingw to my project folder. Have provided the include and lib-mingw directories for Compiler and Linker options respectively in the build options. In the Linker settings tab, I have added glfw3,gdi32 and opengl32. I'm running the sample program given in the documentation page of the GLFW website. The program is compiling. While building a warning and an error message is displayed:
Warning: .drectve `-aligncomm:"__glfw",5' unrecognized
And
init.c undefined reference to `__chkstk_ms'
Have googled a lot, but in vain. Any help would be great.
Today the problem is solved. The problem was with the compiler settings in CodeBlocks. In CodeBlocks, under "Settings" tab "Compiler"->"ToolchainExecutables", it was "Dev C++". I installed TDM-GCC-32 (http://tdm-gcc.tdragon.net/download) 32 bit version. Then changed "Dev C++" with the directory where TDM-GCC-32 is installed in my computer.
Next in "Settings"->"Debugger" option, I selected "GDB/CDB Debugger" and "Default". Then provided the path of gdb32.exe located in the TDM-GCC-32/bin directory.
I think as I had installed Dev C++ before installing codeblocks, Dev C++ was selected by default (not sure). For those who are facing similar problems but DEV C++ is not their case, updating TDM-GCC may help.
However, this DEV C++ compiler was working for older GLFW 2.7. Today, I have also found another problem with this DEV C++ one. I was using freeglut. When I was including iostream along with GL/glut.h similar "undefined reference to `__chkstk_ms'" error message was appearing.
But now, it is ok. Thank you all :)
looks like you need to add library(.lib) with this stuff. .h file has been
deployed already so you need to detect it. Then you can google for library.

OpenCV in Code::Blocks: The application was unable to start correctly (0xc00000be)

I set up OpenCV with Code::Blocks as per this tutorial: http://kevinhughes.ca/tutorials/opencv-install-on-windows-with-codeblocks-and-mingw/.
I've got as far as building the test program at the end successfully, but when I try to run it I get the following error: "The application was unable to start correctly (0xc00000be). Click OK to close the application."
The one thing that is certainly different from the tutorial for me is that I'm working with OpenCV 3.0.0, Code::Blocks 13.12 and the latest version of mingw (number not obvious from their website or the installer).
I found that other people had had this problem in the past, e.g. The application was unable to start correctly (0xc00000be)
However, it has been a long time since that thread was active, I'm working with newer versions of the software and, most importantly, the answer given there didn't help (I compiled openCV with the same mingw that I'm using with Code::Blocks), so I thought this question would be worth asking (sorry if it's not, I'm rather new to this).
Could anybody suggest a fix that might get rid of this error?
A few other things to note:
I didn't download the Code::Blocks that came with mingw as I was advised against it, I got them separately as per the tutorial
I have installed OpenCV and Code::Blocks on my E: drive, though mingw is still on my C:.
I have added both mingw and OpenCV to my PATH variable, and mingw to my Path variable
I have linked the libraries in both the main compiler settings for Code::Blocks and the Build Options of my project.
I'm working from a 64-bit Windows 7 Laptop, but I have done everything 32-bit style as advised in the tutorial.
Thanks in advance!
So, one solution I've found to this problem is to copy all the .dll files from "...\opencv\build\x86\mingw\bin" to the project file (build directory).
Having done that, the project will run fine. This still doesn't (directly) explain why it wont run without those files (at least, several sources including the tutorial imply it should), and so isn't really optimal. I will continue to look for a solution for this so I don't have to clutter every opencv project I make with the .dlls.
However, for anyone simply wanting to get stuck into coding who is having this problem, I recommend that solution.

openGL glx.h missing form xcode 4 mac lion

I'm trying to setup an example project, which uses GLSDK . I set it up with premake, (setting the projects base sdk to 10.6 since I'm on xcode 4) but when I try to compile I get "GL/gl.h not found" from the example files.
So I manually add the opengl framework and change GL/gl.h to OpenGl/gl.h and it works, but then I get the same error for a different line , and now I realize that header doesn't exist in the opengl framework, even though it should.
I can see it getting reference in other programs and i see it example code all the time. But for some reason it doesn't exist on my computer?
Or am I missing something like I usually do. Just for reference I'm tying to set up the example projects here and I'm certain my screwing something up.
http://support.apple.com/kb/HT5293
If you install XQuartz you get X11 which has glx.h

OS X Eclipse C++ Launch Failed - Binary Not Found

I am quite troubled as this shouldn't be causing me such a headache. I've downloaded the most recent Eclipse Indigo and all CDT C++ plugins for MAC OS X 10.7.1/
Upon restarting after installing the above CDT plugins, I've developed a simple 'hello world' c++ application and have tried running the application, "Launch failed. Binary not found." error message. I've read multiple fixes but none have worked. I tried adding the -arch i386 flag to the linker and compiler commands, still no luck.
Has anyone successfully gotten Eclipse C++ running on 10.7.1?????? This blows my mind. I can simply write the same program in VIM and compile it just fine via the terminal and execute just fine. ECLIPSE DOESN'T WANT TO PLAY ALONG.
I will be deeply indebted to anyone who can help!!!!!
EDIT: compiler output
**** Build of configuration Debug for project HelloWorld ****
make all Building file: ../main.cpp
Invoking: GCC C++ Compiler g++ -I/Developer/SDKs/MacOSX10.6.sdk/usr/include -O0 -g3 -Wall -c -fmessage-length=0 -arch i386 -MMD -MP -MF"main.d" -MT"main.d" -o "main.o" "../main.cpp"
Finished building: ../main.cpp
Building target: libHelloWorld
Invoking: MacOS X C++ Linker g++ -arch i386 -dynamiclib -o "libHelloWorld" ./main.o
Finished building target: libHelloWorld
**** Build Finished ****
I am using Eclipse Juno with CDT on a 2007 Macbook running Snow Leopard. I have the two symptoms:
No Binaries folder in Project Explorer, and
The 'Launch failed. Binary not found' error.
I have spent hours searching on Google for an answer, long enough to ascertain that these two symptoms are indicative of any number of problems which have been reported for not quite a decade without adequate resolution. That is a problem right there because after a decade there should have been more than enough input data to provide one troubleshooting procedure somewhere which walks the user step by step through the elimination of all possible causes.
Instead, for hours I have read about a multitude of people, many of whom have resolved their particular problem but all of them seeming to have had to do something slightly different to get there.
This should not be that difficult to resolve. Particularly in cases such as mine [but I am not the only one] when the Console view displays a Build with no errors yet the user can copy the binary file [which Eclipse bizarrely says it can not find] to the Desktop and run it without any problems from either Finder or a bash terminal session.
All of this seems to be pointing rather emphatically toward the lack of adequate indicators in the Mach0 64 binary parser which should be designed to tell us exactly what it needs which it is not seeing.
Admittedly, this is exacerbated in the case of MacBooks like mine which are running a 64bit OS [Snow Leopard] on a 64bit CPU which the manufacturer, unfortunately, hamstrung with a 32-bit bootup kernel. But, be forewarned, I have already tried the -arch i386 g++ switch, and the relinking of g++ to g++-4.0 without any change in the symptoms.
ADDENDUM ADDED 10/07/2012:
I am adding this checklist in the hope of clarifying a Way for the undoubtedly many others who will ask this question in the years to come. This Way reflects what I found to be necessary when using Eclipse Juno with a Mac running Snow Leopard:
1) Go to Preferences->C/C++->New CDT Project Wizard, and under Preferred Toolchains, make sure all the Executable project types are set to MacOSX GCC.
2) This is a biggie. I was able to get a Binaries folder in Project Explorer, and hence be able to run the project after building it, by using a Project name which does not contain dots ['.']. This I learned from another answer here, edited a few hours after my previous message. This requirement is easy to miss, hence a common one particularly if you are Eclipse experienced but only with other languages, because tutorials for other language plugins [such as with PyDev or for Java] frequently have you create Projects with dots in the name. If you have developed that habit with other languages, break it when using CDT for C/C++. Be forewarned, however, that it is not enough to just do a Right-Click and Rename an existing project name this time not using dots. The simplest Way is to delete your old project and create a new one with a name without dots.
3) There are many websites cautioning you to make sure you either use the -arch i386 compiler switch or change the links for /usr/bin/gcc and /usr/bin/g++ to point to gcc-4.0 and g++-4.0 instead of gcc-4.2 and g++-4.2. I created a bash script to ease switching back and forth and investigated if this was necessary. It was not, at least not with my Macbook. Based on what I read at one site from a Mach-O developer, I suspect that the current version of Mach-0 64 goes both ways. Which is a good segue to ...
4) In the Project Properties, not Preferences, go to C/C++ Build->Settings and under Binary Parsers make sure Mach-O 64 Parser is checked. Make sure this, and not the deprecated Mach-O parser, is checked.
5) At this point, after you build your project, several things should be evident in the Project Explorer:
6) There should now be a Binaries folder under project's folder.
7) Within that Binaries folder should now be your executable file. It should have [x86_64/le] next to it if, like me, your Mac is effectively 32bit. Now is not the best time to get into the confusing topic of whether your Mac is effectively 32bit or 64bit. If you do not know, and a lot folks don't because Apple does make it confusing, check out the little app which can be downloaded from http://www.ahatfullofsky.comuv.com/English/Programs/SMS/SMS.html which will tell you What Is Truth. It is free, but the 'price' is that you have to scroll pass the ads at the top of the page reflecting the programmer's political disposition.
For those of you that are new to programming/eclipse/IDEs and get the same error but the solutions above don't work, I solved my "Launch Failed. Binary Not Found." error by doing the following: Simply be sure to build your project ("Project" > "Build All") before attempting to run or debug. I was thinking that the IDE would do the building when I clicked debug or run, but that is not the case (obviously, in retrospect). Newbie lesson learned. Once you build you should see a "Binaries" and "Debug" folder under the root directory of the project.
I was using OS X 10.7.3, if it matters, though I assume the mistake I made is fundamental and any eclipse distro would give the same error.
on mac:
Make sure you have xcode installed. Test it by writing "info g++" you must see proper information about the compiler.
Build your project.
Go to the folder of your project. You should see an executable file in Debug or realise folder, depending to your building configurations. If you d-click on the executable file you should see the result on the terminal.
Back to Ecliipse, from Run/Run Configurations... and then browse to the folder that you have the executable file - one you already found - you can also change build configurations as you wish in that window. And make build automatic for each run.
Run again it should work.
Good luck !
I had the same problem, then I found a solution on this site.
Let me explain shortly;
Create your c++ project,
Have a look at project properties(⌘I),
Select Mach-O parser under binary properties,
Write your codes down,
Do not forget building your project (⌘B) before run.
You should change the settings for your project to build an executable instead of a dynamic library:
Invoking: MacOS X C++ Linker g++ -arch i386 -dynamiclib -o "libHelloWorld" ./main.o`
Go to project properties -> C/C++ Build -> Settings -> Build artifact, and select Executable in the first drop down list.
I am using Eclipse Oxygen and the following fixed my problem:
Right-click on your project and go to properties. Navigate to C/C++ Build > Tool Chain Editor and select MacOSX GCC in the Current toolchain, and Apply and Close.
Build your project with CMD+B and then run it.
I was having the same problem. The answer can be hard to find as the "binary not found" issue has cropped up several times before, with different causes and solutions (selecting the 64-bit parser, etc.).
It turns out that, in my case, the fix was simple: you have to do a manual build, just once, for every new project you create. After that, works as usual.
Details: using a fresh fresh install of Eclipse Indigo Service Release 1 on Mac OS 10.7.2.
If your project name contains a "." (dot), the binary file will not be generated on building project.
Remove all the "."(dots) from the project name and rebuilt it or try creating a new project.
Happy coding!
If you can successfully built but when try to run it getting error:
Possible solution could be adding new configuration with full path to your binary output file
(Run->Run Configuration...->Main->C++ Application):
I solved a similar problem with Eclipse by creating a "Launch Configuration". I am using the Indigo release of Eclipse on OSX Lion with CDT (C/C++ dev environment). I found the option to create a new launch configuration in Project->Properties->Run/Debug Settings.
I encountered this problem after creating and building an empty "Hello World Ansi C Autotools Project". The build process created a working executable as src/a.out. I could run a.out successfully from the terminal but Eclipse did not understand that this was an executable for my project until I created a launch configuration pointing to it. Once I did that I was able to run a.out as usual using the green run button.
I had the same problem, even when i had set the artifact to executable. It was because the shared lib setting was ticked and this causes a dylib to be made even though you have specified an executable.
I go this to run by setting the Builder Type to Internal Builder on the C/C++ Build tab, in the project properties dialog.
No matter which approach to take to solve this issue on your workspace, this problem seemed to have become native to the project that I had created. Neither using the arguments or making sure the gcc version for linking did not work. I did find an intuitive solution. Here it is:to the "...binary not available..." error.
Do the following:(remember the following steps are after you have taken either of the above routes and none of those have solved the issue.
1.) delete everything - the project and the files.
2.) create new project and source files
I had the similar issue but code was different. In File.h file make sure
virtual ~Destructor () {}; //Don't forget Curly braces {}
Above statement shows destructor initialized () and defined with curly braces { } . In my code I forgot to define Destructor.
Hope this helps
I was having the same problem, so I fiddled around a littpe bit and found out that if I clicked on the "profile" button (green play icon with a little clock under it), to the right of the "run" button, my program would Run the next time I clicked on the Run button.
I actually dont know what that did, but it allowed me to run the code.
if anybody knows why this helped, and whether it is an actual solution or not dont hesitate to relpy!