Need a mac victim

[nuclearmistake]

A modified freeglut (with a glutMainLoop that's drivable externally (as we need to do to allow qt's main loop to be happy)) has been included, and should be compiled early in build (building with qtcreator requires running "make qt" or "make freeglut" beforehand).

Also, boost_thread is a new dependency, and should be linked for all targets.

I need a mac tester to pull master, and try "make", and "make qt"... let me know if they work!

[nickavv]

I tried it. I fail with the following:

/bin/sh: cmake: command not found make[1]: *\ [cmake] Error 127

This very well might be my own fault though, I've got some weird stuff going on with my environment lately. Make somebody else try it too

[nuclearmistake]

Install cmake :-P

[nickavv]

Ah, didn't realize it wasn't something I shouldn't have already had. Anyway, here's what I get now:

`Scanning dependencies of target freeglut [ 1%] Building C object CMakeFiles/freeglut.dir/src/fg_callbacks.c.o In file included from /Users/NickAVV/git/GraphicsProject/src/freeglut/src/fg_callbacks.c:29: In file included from /Users/NickAVV/git/GraphicsProject/src/freeglut/src/fg_internal.h:179: /Users/NickAVV/git/GraphicsProject/src/freeglut/src/x11/fg_internal_x11.h:36:10: fatal error: 'GL/glx.h' file not found

include <GL/glx.h>

     ^

1 error generated. make[4]: [CMakeFiles/freeglut.dir/src/fg_callbacks.c.o] Error 1 make[3]: [CMakeFiles/freeglut.dir/all] Error 2 make[2]: *** [all] Error 2 [ 1%] Building C object CMakeFiles/freeglut.dir/src/fg_callbacks.c.o In file included from /Users/NickAVV/git/GraphicsProject/src/freeglut/src/fg_callbacks.c:29: In file included from /Users/NickAVV/git/GraphicsProject/src/freeglut/src/fg_internal.h:179: /Users/NickAVV/git/GraphicsProject/src/freeglut/src/x11/fg_internal_x11.h:36:10: fatal error: 'GL/glx.h' file not found

include <GL/glx.h>

     ^

1 error generated. make[4]: [CMakeFiles/freeglut.dir/src/fg_callbacks.c.o] Error 1 make[3]: [CMakeFiles/freeglut.dir/all] Error 2 make[2]: [all] Error 2 make[1]: [compile] Error 2 make: *** [freeglut] Error 2 `

[nuclearmistake]

try installing Xquartz first... glx is the X11 equivalent of cgl, and Xquartz is X11 for osx

[nickavv]

I already have XQuartz

[franckamayou]

I'll give this a shot tomorrow morning.

[nuclearmistake]

gmmmm... does it work if you replace "glx" with cgl?

[nuclearmistake]

will require a bit of hacking of freeglut's guts... everything from changing GL/* to OpenGL/* in includes to special casing stuff in CMakeLists.txt for mac compatibility... what version of freeglut do you have installed? might be an easier base to use than the latest

[nuclearmistake]

pull again... used the version of freeglut packaged in Xquartz as a base for my modifications... works on linux

[nickavv]

It gets pretty far, but I end up with undefined symbol for architecture errors. They look like these:

Undefined symbols for architecture x86_64: "_XF86VidModeGetAllModeLines", referenced from: _fghChangeDisplayMode in libexpensiveglut_la-freeglut_gamemode.o _glutLeaveGameMode in libexpensiveglut_la-freeglut_gamemode.o "_XF86VidModeGetModeLine", referenced from: _fghChangeDisplayMode in libexpensiveglut_la-freeglut_gamemode.o _glutEnterGameMode in libexpensiveglut_la-freeglut_gamemode.o except there's a whole bunch more of them

[nuclearmistake]

cd into freeglut, and try running:

./configure --prefix=pwd/../expensiveglut make

lemme know if it finishes

[nuclearmistake]

those are the non-shift ~ key around pwd, btw... github decided to turn those ticks into something else

[nickavv]

The ./configure etc line finishes, the make call does not, I get errors like the last ones I posted

On Sun, Apr 14, 2013 at 11:35 PM, Nuclear Mistake notifications@github.comwrote:

those are the non-shift ~ key, btw... github decided to turn those ticks into something else

— Reply to this email directly or view it on GitHubhttps://github.com/UMLComputerGraphics/GraphicsProject/issues/44#issuecomment-16366015 .

[nuclearmistake]

can I get full output of "make configfreeglut; make compilefreeglut" from the src dir?

[nickavv]

Sure, here you go: http://pastebin.com/UZ2gLpff

On Sun, Apr 14, 2013 at 11:43 PM, Nuclear Mistake notifications@github.comwrote:

can I get full output of "make configfreeglut; make compilefreeglut" from the src dir?

— Reply to this email directly or view it on GitHubhttps://github.com/UMLComputerGraphics/GraphicsProject/issues/44#issuecomment-16366154 .

[nuclearmistake]

pull and try again por favor

[nickavv]

Try what again, just a normal make, or the last thing you told me to do?

On Sun, Apr 14, 2013 at 11:53 PM, Nuclear Mistake notifications@github.comwrote:

pull and try again por favor

— Reply to this email directly or view it on GitHubhttps://github.com/UMLComputerGraphics/GraphicsProject/issues/44#issuecomment-16366360 .

[nuclearmistake]

they should use the same commands, so either

[nuclearmistake]

but it's broken... working on it

[nuclearmistake]

do you have mesa installed?

[nuclearmistake]

I got freeglut to compile in my VM... got as far as missing libmagick++, so it should go all the way on real macs owned by people who know WTF they're doing. :-D

[franckamayou]

I get this

 "Magick::Image::write(Magick::Blob*, std::__1::basic_string, std::__1::allocator > const&)", referenced from:
      Texture::load(std::__1::basic_string, std::__1::allocator > const&) in Texture.o
  "Magick::Image::Image(std::__1::basic_string, std::__1::allocator > const&)", referenced from:
      Texture::load(std::__1::basic_string, std::__1::allocator > const&) in Texture.o
ld: symbol(s) not found for architecture x86_64

[nuclearmistake]

So do i. I got the gl stuff to build. Have fun. :-P On Apr 15, 2013 7:25 AM, "franckamayou" notifications@github.com wrote:

I get this

"Magick::Image::write(Magick::Blob*, std::1::basic_string, std::1::allocator > const&)", referenced from: Texture::load(std::1::basic_string, std::1::allocator > const&) in Texture.o "Magick::Image::Image(std::1::basic_string, std::1::allocator > const&)", referenced from: Texture::load(std::1::basic_string, std::1::allocator > const&) in Texture.o ld: symbol(s) not found for architecture x86_64

— Reply to this email directly or view it on GitHubhttps://github.com/UMLComputerGraphics/GraphicsProject/issues/44#issuecomment-16379417 .

[franckamayou]

and when I do a make qt, I get:

include/OpenGL.h:14:12: fatal error: 'GL/glew.h' file not found

and on MY mac, glew.h is in /opt/local/include/GL/glew.h and that GL directory only contains glew.h glxew.h and wglew.h, so even when I give the correct path for glew.h (absolute eh eh) the next error is on GL/gl.h

[nuclearmistake]

Cuz the .pro isnt up to date On Apr 15, 2013 7:50 AM, "franckamayou" notifications@github.com wrote:

and when I do a make qt, I get:

include/OpenGL.h:14:12: fatal error: 'GL/glew.h' file not found

include

       ^

and on MY mac, glew.h is in /opt/local/include/GL/glew.h and that GL directory only contains glew.h glxew.h and wglew.h, so even when I give the correct path for glew.h (absolute eh eh) the next error is on GL/gl.h

— Reply to this email directly or view it on GitHubhttps://github.com/UMLComputerGraphics/GraphicsProject/issues/44#issuecomment-16380293 .

[nuclearmistake]

Sudo port install glew On Apr 15, 2013 7:50 AM, "franckamayou" notifications@github.com wrote:

and when I do a make qt, I get:

include/OpenGL.h:14:12: fatal error: 'GL/glew.h' file not found

include

       ^

and on MY mac, glew.h is in /opt/local/include/GL/glew.h and that GL directory only contains glew.h glxew.h and wglew.h, so even when I give the correct path for glew.h (absolute eh eh) the next error is on GL/gl.h

— Reply to this email directly or view it on GitHubhttps://github.com/UMLComputerGraphics/GraphicsProject/issues/44#issuecomment-16380293 .

[nuclearmistake]

And you need to update the flags. LPP like in the makefile On Apr 15, 2013 7:54 AM, "Eric McCann" nuclearmistake@gmail.com wrote:

Sudo port install glew On Apr 15, 2013 7:50 AM, "franckamayou" notifications@github.com wrote:

and when I do a make qt, I get:

include/OpenGL.h:14:12: fatal error: 'GL/glew.h' file not found

include

       ^

and on MY mac, glew.h is in /opt/local/include/GL/glew.h and that GL directory only contains glew.h glxew.h and wglew.h, so even when I give the correct path for glew.h (absolute eh eh) the next error is on GL/gl.h

? Reply to this email directly or view it on GitHubhttps://github.com/UMLComputerGraphics/GraphicsProject/issues/44#issuecomment-16380293 .

[franckamayou]

if you get a chance may be you can try to update the .pro file

[franckamayou]

still not working for me...

[nuclearmistake]

Can you handle magic++? I had to use c++11 standard for boost to not freak out on 64 bit On Apr 15, 2013 8:06 AM, "franckamayou" notifications@github.com wrote:

if you get a chance may be you can try to update the .pro file

— Reply to this email directly or view it on GitHubhttps://github.com/UMLComputerGraphics/GraphicsProject/issues/44#issuecomment-16380854 .

[nuclearmistake]

how bout now?

[franckamayou]

expensiveglut/include/GL/freeglut_std.h:122:10: fatal error: 'GL/gl.h' file not found

http://pastebin.com/BpPTvaec

on the mac gl.h is in OpenGL.framework or /opt/X11/include/GL but not in the same place as glew.h... (see screenshots).

[nuclearmistake]

I know... this is compiling it native... do you have Xquartz installed? glew and xorg-vesa installed through macports?

I got past those build steps in a mac VM I threw together at 2 AM

[franckamayou]

Xquartz and glew yes, WTH is xorg-vesa?

[nuclearmistake]

port install xorg-server mesa *rather

[nuclearmistake]

In about 15 minutes, I'll be stopping development for the day.

I worked about 12 hours yesterday trying to make a.exec() and glutMainLoop happen at the same time... because both are blocking calls, and don't like to be trivially threaded with a boost::thread wrapping them.

I was successfull on linux, and mostly successful on mac.... where success includes compiling and linking against customized freeglut.

Because it NEEDS a customized freeglut to work, using the OpenGL framework is not an option.

If you have another idea, by all means... but without a work around for a.exec and glutMainLoop both blocking, the qt+glut implementation is not viable.

[franckamayou]

well the way I had it set up yesterday before you took over was working on the mac, a.exec() and glutMainLoop() were running at the same time on the same thread. @ltran1 also had something working on the Qt-integration-linux branch, did you check that out? He was using Qthreads...

and by working, I mean that both windows were coming up and were independent of each other and you could switch back and forth. I hadn't tried any UI connection yet.

[nuclearmistake]

they were coming up, but nothing was drawing in the glut window.

[nuclearmistake]

because the mainloop wouldn't start until you closed the qt window

[franckamayou]

look at the qt-integration-linux branch before you go

[nuclearmistake]

it's 4 days old, and: Binaries/MONOLITH.cpp: In member function ‘void MONOLITH::init()’: Binaries/MONOLITH.cpp:41:67: error: ‘glGetUniformLocation’ was not declared in this scope Binaries/MONOLITH.cpp:75:37: error: ‘glUniform1f’ was not declared in this scope make: *\ [debug/obj/MONOLITH.o] Error 1

[franckamayou]

go into the separate GraphicsProject and do qmake then make

[nuclearmistake]

lol.... in the GraphicsProject folder? The one that has .o files checked in?

It also has hardcoded paths that don't exist: g++ -m64 -Wl,-O1 -o GraphicsProject main.o Camera.o Cameras.o Engine.o mat.o meshMapping.o Object.o Particle.o ParticleSystem.o Scene.o Screen.o SpelchkCamera.o Texture.o TextureMan.o Timer.o TransCache.o Transformation.o vec.o glut_callbacks.o InitShader.o model.o modelFunctions.o ObjLoader.o Util.o mainwindow.o moc_mainwindow.o -L/usr/X11R6/lib64 -lGLU -lGLEW -lglu -lm -lMagick++ -lQt5OpenGL -L/usr/lib/x86_64-linux-gnu -lQt5Widgets -lQt5Gui -lQt5Core -lGL -lpthread /usr/bin/ld: cannot find -lglu collect2: ld returned 1 exit status make: *\ [GraphicsProject] Error

and has:

a.exec(); /* PULL THE TRIGGER */ glutMainLoop();

which will never work.

that's why people don't usually use glut and qt.

try the latest version of master.

[nuclearmistake]

check out the version you had yesterday, or the qt-integration branch if you don't believe me... but they are both blocking calls.

If they weren't, then qt applications without a separate mainloop would exit as soon as the window appeared.

[nuclearmistake]

I just pushed a version that builds on linux without even having ImageMagick installed... the libraries and includes have a suffix, so if the e build of ImageMagick works, the build of the binaries should too

[nuclearmistake]

sudo port -v install freetype +bytecode; sudo port install librsvg; sudo port install +graphviz +gs +wmf +jbig +jpeg2 +lcms; sudo port install jpeg

for the latest version