Setting up programming environment

kirba · 11-15-2012, 07:26 AM

Hi everyone!

Im making a simple game application using C++ and openGL for my uni.
Im trying to get a proper working environment at home and problems come up as i do this.
Some of them i have managed to sort out but others appear.

Now I am at the stage where I have installed eclipse, a compiler and downloaded glew and glut libraries. I believe i have liked them to eclipse as well but not 100% sure.

Well, I need someone whos relevant to guide me or tell me exactly what i need from scratch to start developing using OpenGL.

"Hello World" compiles and runs so im on the right path.

The other thing is that when i include glut and glew in my code, it used to underline them as it did not recognise them but now that's sorted as well. The underlining is gone (im guessing i did the linking right) but it won't compile because of this one error.

13:01:28 **** Incremental Build of configuration Debug for project second project ****
make all
Building target: second project
Invoking: Cross G++ Linker
g++ -o "second project" ./src/second\ project.o -l/usr/include/GL
/bin/ld: cannot find -l/usr/include/GL
collect2: error: ld returned 1 exit status
make: *** [second project] Error 1

13:01:29 Build Finished (took 434ms)

Please I need help with this as I can't start working on the project.
If I made this post in the wrong forum, someone let me know asap!

Cheers!

markush · 11-16-2012, 05:47 PM

Hi,

which distribution are you using? and how did you install your programming-environment?

Markus

theNbomr · 11-16-2012, 07:01 PM

Not sure how the compiler commandline was composed for your environment, but the part '-l/usr/include/GL' looks wrong. It should probably be in two different parts; maybe just one.

Code:

g++ -o "second project" ./src/second\ project.o -lGL -L/usr/include

Still, that also looks wrong, since libraries are not supposed to be in /usr/include, which naturally is for C header files. You need to find (probably with the locate utility) libGL.so, or some version of it. Whatever directory it is found in should be the argument to the -L compiler option.

For the gory details on compiler options:

Code:

man gcc

--- rod.

kirba · 11-17-2012, 09:00 AM

I used terminal for everything. I installed eclipse, gcc and GL libraries (glew and glut).
I'm using fedora by the way.

So if i get this right, I have to locate the libraries and move them to a different folder(?).

$ locate libGL.so
/usr/lib64/libGL.so
/usr/lib64/libGL.so.1
/usr/lib64/libGL.so.1.2

I don't understand what I am to do with those.

*I installed eclipse 2 times. The first time using add/remove software application but installed the java version by accident (or it must have been the only eclipse i was seeing on the screen).
So I had to install the c++ version and so I did using terminal this time. I followed a simple guide on how to get it. Now i have 2 versions of eclipse, one (the first installation) that i can just run from the applications and the other (2nd installation c++) which is placed in /opt and doesnt come up in the applications screen. I can only run it from the folder.
Don't know if any of this is relevant but I thought of mentioning just in case.

theNbomr · 11-17-2012, 10:02 AM

No, you don't move them. You just use the appropriate compiler arguments to point to them. The '-l' (minus ell) argument tells the compiler/linker the name of a library to link. The '-L' argument tells the compiler/linker the name of a directory to add to its standard list of places to look for libraries.
BTW, when your compiler/Makefile says 'Cross G++ Linker', does that imply that you are building code for a non-native target architecture? Or does the word 'Cross' have some other meaning here? If you are doing cross development, that adds several levels of complexity. For cross development, you will need a full cross toolchain, as well as libraries for your target architecture. Usually, that means building those libraries, and installing them on the target host. If you are struggling with the basics like this, then you are really up against it, and have a lot of learning ahead. I would completely forget about using Eclipse in such an environment, as it will only add complexity that you don't need right now.

--- rod.

kirba · 11-17-2012, 10:36 AM

Could you explain to me in simple words why am i encountering these errors? Is it a matter of missplacing libs or linking failure?
Cheers

theNbomr · 11-17-2012, 12:06 PM

I have already spelled it out as simply as I can make it. In order to link with a particular library, the linker needs to be told to do so. This is done with the '-l' linker option. In your case, the library is libGL, so your compiler option would be '-lGL'. In order for the linker to know where the specified library lives in your filesystem, it has to be told, unless it is in one of the compilers standard places to look for libraries. The way you tell the linker where to look for libraries is with the '-L' option, which takes as an argument, the name of a filesystem directory. In your case, the directory of interest seems to be /usr/lib64, so your commandline argument to the linker also needs '-L /usr/lib64'.
There is nothing I can do to break it down any further than this. If something about this doesn't make sense, please tell me what it is.
--- rod.

kirba · 11-17-2012, 12:22 PM

Hi again and thanks for replying. I understand what needs to be done but I don't know how to achieve this.

Ok so this is what i need to use gcc [-Idir...] [-Ldir...] right ?
the dir for -L would be /usr/lib64.
What about the -l ?

Is it possible to give me a complete command line for it ?

theNbomr · 11-17-2012, 12:47 PM

I cannot give you a complete compiler commandline with knowing all of the files you are trying to compile &/or create. Please read what I have written; I've already answered the question of compiler access to libraries:

Code:

-lGL -L /usr/lib64

--- rod.

kirba · 11-17-2012, 01:20 PM

Ok basicaly I was trying to link the libs into eclipse without using the terminal.
I am getting my head around the problem finally.
There's only 1 source file that is to be compiled so far.

This is what i got:

Code:

$ gcc -lGL second.cpp -L /usr/lib64
/tmp/ccxJt9ub.o: In function `render()':
second.cpp:(.text+0x45): undefined reference to `glutSwapBuffers'
/tmp/ccxJt9ub.o: In function `main':
second.cpp:(.text+0x69): undefined reference to `glutInit'
second.cpp:(.text+0x73): undefined reference to `glutInitDisplayMode'
second.cpp:(.text+0x82): undefined reference to `glutInitWindowSize'
second.cpp:(.text+0x8c): undefined reference to `glutCreateWindow'
second.cpp:(.text+0x96): undefined reference to `glutIdleFunc'
second.cpp:(.text+0xa0): undefined reference to `glutDisplayFunc'
second.cpp:(.text+0xa5): undefined reference to `glewInit'
second.cpp:(.text+0xaa): undefined reference to `__GLEW_VERSION_2_0'
second.cpp:(.text+0x10e): undefined reference to `glutMainLoop'
collect2: error: ld returned 1 exit status

It's still giving me errors and I told it where to look, what else must be included ?

theNbomr · 11-17-2012, 01:34 PM

As I said before, if you don't already know what you're doing, using Eclipse just adds weight. Start out from first priniciples where you will learn what all of the Eclipse settings and configuration questions actually mean.
For your present problem, it looks like you need to add another library. Perhaps 'libglut'?
Add it to the same commandline as you did for libGL. If the library is in the same directory as libGL, then adding another '-L' option is not necessary.

--- rod.

kirba · 11-17-2012, 01:59 PM

Ok I get this...

Code:

# rpm -i freeglut-2.8.0-3.fc17.x86_64.rpm
	package freeglut-2.8.0-7.fc17.x86_64 (which is newer than freeglut-2.8.0-3.fc17.x86_64) is already installed
	file /usr/lib64/libglut.so.3.9.0 from install of freeglut-2.8.0-3.fc17.x86_64 conflicts with file from package freeglut-2.8.0-7.fc17.x86_64

However when i do this

Code:

gcc -lGL second.cpp -L /usr/lib64

i still get the same results...
Any ideas ?

The thing that confuses me the most is that while on eclipse, I went on project properties > C/C++ build > Settings and added /usr/include/GL (not /usr/lib64) to the libraries. After doing that, the underlining was gone (meaning it started to recognise the gl code). Anyway i will not bother with it for now, just pointing it out in case it helps to make sence.

theNbomr · 11-17-2012, 07:08 PM

You installed a package that we assume has a library containing the undefined references. Now you have to link to the library. First, you have to find it, so you can tell the linker where it is, just like you did for the first (libGL) library. You also have to tell the linker to use it, just like you did for the first library. I will assume the library is called libglut.so I don't know where it got installed; you will have to figure that out and modify the following accordingly.

Code:

gcc second.cpp -L /usr/lib64 -L /wherever/libglut.so/is -lGL -lglut

The reason that pointing Eclipse to the include/GL directory made Eclipse happy is that it was able to find C header files there. You should now be seeing a pattern here.

--- rod.

Elv13 · 11-18-2012, 01:12 AM

Code:

su -
yum install freeglut-devel

or check how it is called. Be sure to have all the development libraries correctly installed. Do _NOT_ use the "rpm" command directly and do not install things without using repositories (for the former, there some exceptions). If you want to develop using a library, make sure the -devel is installed too. It probably wont solve your problem and you probably already did it, but I can't take it for granted reading the previous comments.

kirba · 11-18-2012, 10:40 AM

I already have freeglut-devel to it's latest update.
Ok I think I am on the right path!

This is what i get now:

Code:

[kirba@kirba ~]$ locate libglut.so
/home/kirba/Downloads/usr/lib64/libglut.so.3
/home/kirba/Downloads/usr/lib64/libglut.so.3.9.0
/usr/lib64/libglut.so
/usr/lib64/libglut.so.3
/usr/lib64/libglut.so.3.9.0
[kirba@kirba ~]$ locate second.cpp
/home/kirba/workspace/second_project/src/second.cpp
[kirba@kirba ~]$ cd /home/kirba/workspace/second_project/src
[kirba@kirba src]$ gcc second.cpp -L /usr/lib64 -L /usr/lib64 -lGL -lglut
/tmp/ccbvzzGe.o: In function `main':
second.cpp:(.text+0xa5): undefined reference to `glewInit'
second.cpp:(.text+0xaa): undefined reference to `__GLEW_VERSION_2_0'
collect2: error: ld returned 1 exit status

Still not compiling but most of the errors are gone.
Is it OK to have my libs here /usr/lib64/ ?
Also here is the code the code so far.

Code:

#include <stdlib.h>
#include <GL/glew.h>
#ifdef __APPLE__
# include <GLUT/glut.h>
#else
# include <GL/glut.h>
#endif
#include <stdio.h>

static int make_resources(void)
{
    return 1;
}

/*
* GLUT callbacks:
*/
static void update_fade_factor(void)
{
}

static void render(void)
{
    glClearColor(1.0f, 1.0f, 1.0f, 1.0f);
    glClear(GL_COLOR_BUFFER_BIT);

    glutSwapBuffers();
}

/*
* Entry point
*/
int main(int argc, char** argv)
{
    glutInit(&argc, argv);
    glutInitDisplayMode(GLUT_RGB | GLUT_DOUBLE);
    glutInitWindowSize(400, 300);
    glutCreateWindow("Hello World");
    glutIdleFunc(&update_fade_factor);
    glutDisplayFunc(&render);

    glewInit();
    if (!GLEW_VERSION_2_0) {
        fprintf(stderr, "OpenGL 2.0 not available\n");
        return 1;
    }

    if (!make_resources()) {
        fprintf(stderr, "Failed to load resources\n");
        return 1;
    }

    glutMainLoop();
    return 0;
}