Command-line Options and Third-party Libraries

We look at how to specify command line options, add to header file search path, and link with libraries such as GLEW, Expat, JPEG, and PNG on:

Please let me know if you have any correction or addition. Thanks.

If you don't know how to install or use OpenGL and GLUT or are unfamiliar with Xcode or Visual Studio, you may want to read the Building OpenGL/GLUT Programs course note. To use GLFW instead of GLUT, you can read the Building OpenGL/GLFW Apps course note instead.


version: Fedora 15
gcc: 4.6.3
version: Red Hat Enterprise Linux Workstation release 6.3 (Santiago)
kernel: 2.6.32-279.el6.x86_64
gcc: 4.4.6

If you're running Linux, you can use:

  % yum list available '*<pkg>*'

to check if pkg is available. Last I checked, all of GLEW, libexpat, libpng, and libjpeg are available for:

  % yum install <pkg>

If you want the latest version of these, you can download them from their project pages:
GLEW, Expat XML Parser, libpng, libjpeg.

If you don't have root privileges to install these packages system wide, install them on your home directory and tell gcc/g++ to link against the static version of these libraries by simply listing them on the command-line:

  gcc . . . <your local lib path>/lib<pkg>.a

You may also need to tell gcc/g++ where to search for header files using the command-line option:

  -I <your local include path>

(which may be specified multiple times, once per directory.

To display OpenGL windows remotely, run:

  client% ssh -Y server

It displays faster if you let the client OpenGL do the rendering on local GPU with:

  server% setenv LIBGL_ALWAYS_INDIRECT 1

If your remote OpenGL terminates with the error message:

X Error of failed request: BadWindow (invalid Window parameter)
  Major opcode of failed request: 4 (X_DestroyWindow)

when you try to create a double-buffered glut window or just because the client is running Mac OS X, indirect is the only way to get the remote OpenGL app to display. Unfortunately, code using shader usually crashes on glCreateProgram() or, on Mac OS X client, glGenVertexArrays() (perhaps due to Apple's use of glGenVertexArraysAPPLE()?). So if your code relies on shaders, vertex array, object buffers, or any of the "modern" OpenGL features, you should try to just run it locally (3D gaming setups usually send the frames as a video stream, not rendering each frame remotely).

Mac OS X:

version: Lion 10.7.2 (11C2002)
kernel: Darwin 11.2.0
Xcode: 4.2.1
gcc: 4.2.1

To specify command-line options, from Xcode 4.2.1 menu click "Product→Edit Scheme" (Fig. 36). Go to the "Arguments" tab and click the '+' sign below "Arguments Passed On Launch". Type in your command-line options (Fig. 37).

To specify your working directory, e.g., where your shader, scenegraph, and/or texture image files are to be found, click on the "Options" tab of "Product→Edit Scheme". Next to "Working Directory" check "Use custom working directory:" and type in your working directory.

To add header or library search path, click on your project name at the top of the left pane to bring up the build panel. Click on the "Build Settings" tab. On the second menu of the panel, click on "All". To add header search path, scroll down (or search for) "Header Search Paths". Double click to the right of "Header Search Paths" and type in your header search paths. Similarly for "Library Search Paths".

To add additional libraries, click on your project name at the top of the left pane to bring up the build panel. Under "Build Phases→Link Binary With Libraries", hit the '+' at the bottom of the list. Scroll down the list of frameworks that comes up until you see the library you want. Select it and click "Add".

The Expat XML Parser usually comes standard with Mac OS X and doesn't need to be reinstalled. If you don't already have libpng & libjpeg installed, click on the link to download and install. The installation would most likely put the header files in /usr/local/include/ and the libraries in /usr/local/lib/. You'll need to add these paths to your header and library search paths respectively, per instructions above.

In my experience using ARB GLSL extensions, they are already part of OpenGL.framework, so you don't need GLEW to use these extensions. The only caveat is that the four gl*VertexArray*() functions have APPLE appended to them and that GL_RGB*F still need _ARB appended.


8.1 Enterprise, 7 Enterprise
Visual Studio 2013 12.0.30723.00 Update 3, 2012 11.0.51106.01 Update 1, 2010 10.0.420219.1 SP1Rel
.NET Framework version 4.5.51641, 4.5.50709, 4.0.30319 SP1Rel

To specify command-line options, add header files, dlls, libraries:

To use buffer object or GLSL on Windows, you'll need GLEW. Download the latest GLEW binaries for Windows and distribute its files as follows:

(The MX version of the GLEW libraries are for use with multiple contexts, so unless your programs use multiple contexts, you don't need them.)

In VS, add glew32.lib; to your "Additional Dependencies" under the "Configuration Properties→Linker→Input" for "All Configurations".

In your OpenGL source files, include in order:

  #include <GL/glew.h>
  #include <GL/glut.h>
  #include <GLFW/glfw3.h>

and call glewInit() after glutCreateWindow().

Some of our projects require the following libraries: the Expat XML Parser, libpng, and libjpeg. Only the 32-bit version of libexpat for Windows is available pre-built from sourceforge. Similarly, the pre-built Windows binaries of libpng and libjpeg are either 32-bit only, not the latest version, and/or are not MinGW compatible. I've prepared libexpat, libpng, and libjpeg packages that are of the latest version as of the time of writing and support both 32-bit and 64-bit MSVC and MinGW builds (the 32-bit version of libexpat is the one from sourceforge).

You could install the dll, lib, and .h files of these libraries into your VC or MinGW toolchain directories similar to the installation of GLEW above, or of GLUT or GLFW.


1.7.31-3 (64 bit NT-6.3), 1.7.7(0.230/5/3 NT-6.1)
gcc: 4.8.3, 4.7.3

Since we're building WGL instead of GLX apps, we can't use the GLEW, PNG, JPEG, and Expat libraries installed by Cygwin's setup program. Instead, we'll need the MinGW version of these. The GLEW Windows binaries above are incompatible with Cygwin and MinGW. Instead, you can download GLEW for MinGW I've prepared for the course. The package contains both 32-bit and 64-bit libraries. As noted in the Windows section above, the pre-built binaries of libexpat, libpng, and libjpeg available on the Web are either 32-bit only, not of the latest version, and/or not MinGW compatible. The above libexpat, libpng, and libjpeg packages are of the latest version at the time of writing and support both 32-bit and 64-bit MSVC and MinGW builds.

If you decide to use the 32-bit libraries, remember to use a 32-bit (i686*) compiler toolchain to build your 32-bit programs. When linking against a library, unlike Visual Studio, the MinGW/Cygwin linker looks for either lib<pkg>.a or <pkg>.lib, not lib<pkg>.lib. That constraint aside, you can freely change your static library names as long as you specify the same name when building the program. The runtime library/dll, on the other hand, must be called exactly what the statically linked stub is expecting it to be. Also remember that the runtime library path must be in your PATH environment variable. If the linker complains of ___vsnprintf not found, specify the linker option:


Last updated Dec. 7, 2015 by Sugih Jamin