OpenGL 3.x Development

Question

Level 1

0 points

OpenGL 3.x Development

I have a few questions for which I have not found the answers despite a lot of searching.

I have a new MacBook Pro running OS X Lion 10.7.3 and XCode 4. I have succeeded in building both a static and a dynamic library and well as a few applications. I would like to add my libraries to XCode so they show up under XCode under Build Phase - Link Binary with Libraries. I tried placing them in /usr/lib but they do not show up as desired. I looked for /usr/local/lib but I don't find that directory on my macbook. How can I get my libraries to show up under XCode under Build Phase - Link Binary with Libraries?

My next question concerns developing OpengGL 3.x applications for OS X Lion. I don't find the usual extension libraries such as GLEW and GLEE. I could, of course, download and use them. However, I would prefer to use whatever libraries are built into the mac and XCode. I do find the opengl framework under XCode under Build Phase - Link Binary with Libraries. And, I notice that it contains the headers gl3.h and gl3ext.h. Are these the prefered headers (and associated library code) to use for building OpenGL 3.x applications for OS X Lion (and presumably iOS) applications?

Thanks,

David

MacBook Pro (13-inch Late 2011), Mac OS X (10.7.3), XCode 4 OpenGL 3.x

Posted on Apr 14, 2012 5:07 AM

Reply

Answer 1

etresoft

Level 9

56,686 points

Apr 14, 2012 5:54 AM in response to dcox1776

I don't know anything about OpenGL.

For the libraries, it can be a tricky question. If you include external libraries with your application, how do you plan to install them? The preferred method now is to include them inside your application bundle. Then use "install_name_tool" in a Run Script phase to setup a linkage that is entirely self-contained to your application.

You can install your libraries anywhere you want. The best place would be ~/Library/Frameworks. You will build against that library and then copy it inside your application bundle so it will run stand-alone on a user's machine that doesn't already have your framework.

Reply

Answer 2

dcox1776 Author

Level 1

0 points

Apr 16, 2012 8:20 AM in response to etresoft

Regarding libraries, I think it would be convenient to be able to add libraries so that they show up in XCode under Build Phase - Link Binary with Libraries.

I tried placing my libraries in ~/Library/Frameworks. However, they did not show up in the list of libraries in the Build Phase - Link Binary with Libraries dialog. I suspect that getting user libraries to show up in this dialog is not possible?

Reply

Answer 3

Apr 16, 2012 10:49 AM in response to dcox1776

Third-party frameworks and libraries show up for me in the dialog when I install them in /Library/Frameworks. If your library still does not show up in the dialog, you can always click the Add Other button in the dialog. Clicking the Add Other button opens an Open panel where you can locate the library you want to add.

Apple's OpenGL framework has the header glu.h, which has the function gluCheckExtension() that can check for OpenGL extensions like GLEE and GLEW do. There's no reason you can't use GLEE or GLEW. With GLEE all you have to do is add the files glee.c and glee.h to your project so you don't have to go through the hassle of creating a library.

iOS uses the header files gl.h and glext.h, but it uses the ones in the OpenGL ES framework, not the OpenGL framework.

Reply

Answer 4

dcox1776 Author

Level 1

0 points

Apr 16, 2012 7:12 PM in response to Mark Szymczyk

Thanks Mark. I placed both libGLEW.a and libGLEW.dylib in /Library/Frameworks. However, only libGLEW.dylib shows up in the dialog. In fact the only libraries that the dialog displays are dynamic. I guess to add static libraries you have to click the Add Other button.

Regarding OpenGL 3.2, I did find this specification at opengl.org:

http://www.opengl.org/registry/doc/glspec32.core.20091207.withchanges.pdf

In this document there is some discussion about gl3.h. I quote the relevant text:

"When platforms became common where the OpenGL SDK (library and header files) were not necessarily obtained from the same source as the OpenGL driver, such as Microsoft Windows and Linux, <GL/gl.h> could not always be kept in sync with new core API versions and extensions supported by drivers. At this time the OpenGL ARB defined a new header, <GL/glext.h>, which could be obtained directly from the OpenGL Extension Registry (see section I.1).

The combination of <GL/gl.h> and <GL/glext.h> always defines all APIs for all profiles of the latest OpenGL version, as well as for all extensions defined in the Registry.

<GL3/gl3.h> defines APIs for the core profile of OpenGL 3.2, together with ARB extensions compatible with the core profile. It does not include APIs for features only in the compatibility profile or for other extensions.

<GL3/gl3ext.h> defines APIs for additional ARB, EXT, and vendor exten- sions compatible with the core profile, but not defined in <GL3/gl3.h>. Most older extensions are not compatible with the core profile.

Applications using the OpenGL 3.2 compatibility profile (see appendices H and E) should #include the traditional <GL/gl.h> and <GL/glext.h> headers.

Applications using the core profile should #include the new <GL3/gl3.h> and <GL3/gl3ext.h> headers introduced with OpenGL 3.1.

By using <GL3/gl3.h> and <GL3/gl3ext.h>, instead of the legacy <GL/gl.h> and <GL/glext.h>, newly developed applications are given in- creased protection against accidentally using a “legacy” feature that has been re- moved from the core profile This can assist in developing applications on a GL implementation that supports the compatibility profile when the application is also intended to run on other platforms supporting only the core profile.

Developers should always be able to download <GL3/gl3.h> and <GL3/gl3ext.h> from the Registry, with these headers replacing, or being used in place of older versions that may be provided by a platform SDK. "

It seems that if you use gl.h (or gl3.h for the 3.2 core profile), then you shouldn't need to use GLEW. Yet, most other documentation suggests using GLEW or GLEE. However, I have not found an explanation for why.

Reply