linux users?

just wondering:

who’s on linux?
what distribution?

we’re assembling a team now for OF linux so let us know –


i am interested but it would be nice to get a bit more info on the current state of the library under linux. What about those docs from the guy in barcelona that managed to get it running? I run debian, ubuntu and puredyne




sorry I missed this post -

here are the linux ports with the comments from the people who sent them on to us:

v.0.01 ----

The README is not very rigorous but it gives an idea.

v.0.02 ----

i got the image loading example compiling in 0.02…

i’ve uploaded a stripped down tree to…-nux.tar.gz
(mirrored at:

cd v0.02/apps/imageLoaderExample ; make ; cd bin ; ./imageLoaderExample

i’ve included binaries for fmod and rtaudio. GLee is in there too, but
not currently used.

ideally i should just have the source for rtaudio in there and have the
makefile compile it as needed. that’s uglier than linking to an
installed library, but since rtaudio doesn’t seem to get packaged as a
library by anyone, it would be a passable solution.

it expects freetype2 and freeimage to have been installed, which should
be the case if you got 0.01 working.

if you move the build directory after building, the app won’t load
because it stores an absolute path for the fmod library. i think i know
a workaround for this but it’s annoying enough not to bother with on a
first cut.

some questions to linux heads out there:

is there anyway to do all libs locally, as opposed to globally as we do for the most part in osx and pc, or does this not-jive with the linux way of doing things?

what do we do as an alternative to quicktime? is there a general library for loading videos? forgive my ignorance, but I couldn’t find the equivalent to quicktime or directshow (although V4L is the equivalent for grabbing)

can someone add patches for ofVideoGrabber and ofVideoPlayer ?

is there anything else that makes openFrameworks hard to work with in linux? We’ve not put linux in the codebase yet, but we would we be very happy to work with someone to patch the code for linux so that all the examples compile… that would be our first goal. If you are interested in helping or testing, let us know on the forum or offline (several have already contacted us re: linux)


I did some research on OF for linux…
Some suggestions for video libraries:

  • ffmpeg for video playing
  • video for linux for video grabbing e.g. libfg
    (V4L may not support firewire, but programs like Kino do, so maybe a custom patch is required)

Getting all the examples to compile (at least the non-video ones) are easy if you use system wide libraries…
Not using system wide libraries is a bit of a pain in the proverbial, but it’s possible by either

  1. setting an option to the linker to tell it where the local library is
  2. set an environment variable to tell the binary executable where to find the shared library i.e. $LD_LIBRARY_PATH
    The first option seems the tidiest without resorting to script files and wrappers. I think it hardcodes the library path into the executable, which might cause problems if you then try and take the file out of the OF directory structure.

Here’s my version of the Makefile from the imageLoaderExample of v0.02.1_linux, which didn’t work out of the box for me. Most notably is my use of a local copy of the FreeImage library…I’m not using the system wide one. I also created a symbolic link in the FreeImage directory that points to the shared library. The ‘ldd’ command prints shared library dependencies and confirms this:

$ ldd ./imageLoaderExample => /usr/lib/ (0x00105000) => /usr/lib/ (0x00d8c000) /home/grimus/openframeworks/v0.02/apps/imageLoaderExample/…/…/libs/fmod/lib/ (0x006fc000) => /home/grimus/openframeworks/v0.02/apps/imageLoaderExample/…/…/libs/FreeImage/ (0x00237000)

The Makefile is here:

The -Wl,-rpath compiler option allows local libraries…Hope this helps.

hey thanks!

cool that you are working on it. We really appreciate it and your feedback.

can I ask a simple question about the shared objects, which is:

are there any differences between “.so” and “.dlls” in windows? If not, why can they not just go in the same directory as the executable? (the idea being you give someone a folder with the exe, the dlls and the external files) ?

(I’ve googled, but stuff I find is pretty hardcore, like this)

the idea being that a person loading your app doesn’t need to install any libs to get your app to run. That’s the nice benefit to .dlls on windows - while it makes the directory path pretty gnarly, I can easily pass the whole folder (“exe, dll, files”) to another machine that doesn’t have glut, opencv, freeImage and freetype installed and it will run fine. Something obviously need to be installed, like quicktime (the qt based OF code fails if qt is not installed on the machine) but for the most part, the external libs don’t need to be installed.


take care,

Firstly, that link you looked at is ghastly. It’s more about dissecting the internals of .dll vs .so file I think.

More useful are:…-aries.html

I understand exactly what you want, but I don’t think it’s completely possible. Basically a user will have to run ‘make’ before running an executable the first time, not like Windows say, where you can just drop the .dlls in the same folder and then run a binary. But this is not such a big deal…If you’re coding in linux, you’re expected to know what a makefile is. What does peeve me though, its when I download some linux source, compile it, and then try to install it, and it fails…because then I have to look through the various configuration files to figure out what went wrong and somehow fix it. I also don’t think we’ll get around the problem of needing to recompile whenever the OF directory structure is moved (e.g. fmod…I was deluded last night), unless we make the shared libraries globally visible, which for the moment we’d like to avoid.

When you put the .so (shared libraries) files in the same folder, unless you have specified somewhere that this is where you should expect them, they will be ignored, just like if you try and run a locally compiled executable file, if you don’t prefix it with ‘./’ the system will look in its various /bin directories trying to find it, and will fail.

For shared libraries, you can fix this by either setting the environment variable LD_LIBRARY_PATH to point to the library:
e.g. export LD_LIBRARY_PATH=’/home/grimus/of/apps/libs/’

Or you can use the -rpath option to the linker (ld).
Using gcc, you need to pass it the -Wl option to communicate with the linker (as gcc is acts as a proxy to the linker).
What this does is hard code the location of the library into the compiled executable…so that if you move the exe or the lib, you can no longer run the program…unless you run ‘make’ again. This I think is what we’ll have to do, short of creating a global ‘/usr/local/openframeworks/’ structure with all the libs and headers in it (which is what most other linux programs do).

So in brief, yes, there are differences between .dll and .so
and yes, a person loading my app won’t need to install all the libs, provided they have the OF directory structure intact and provided they run ‘make’ in the appropriate directory the first time they want to run something.
At least, this is my analysis!

Some initial investigations into linux video playback - I had a look at ffmpeg and spent ages trying to compile an example under C++. The more recent versions appear to no longer have any decent support for compiling under C++, it’s a strictly C project it seems. I got the C examples working, but…

So I found FOBS. Ugly name for a useful C++ wrapper to ffmpeg.
FOBS has been successfully tested in MacOS X, Linux and Win32 (MinGW) platforms, which could be useful to OF beyond just linux perhaps. After another less arduous compilation battle (missing linker directives &#¤#1%!) than the first, I got it working. The api seems fairly accessible, much more so than ffmpeg. Next step is to try and get it into openframeworks shape. This beast will handle all manner of codecs.

I am using Ubuntu feisty, and I can have openFrameworks working using some custom makefile,
maybe it could be a good thing to use SDL as an underlying library (rather than GLUT) since it already contains a large part of what’s needed for visual and audio creations ?

hi -

we are interested in wrapping glut (and not sdl, irrlicht or someother libraries) because we want it to be:

a) not too opaque about how we are doing what we are doing (loading images, fonts, etc)

b) not a huge api of an underlying library that might be hard to pick up.

Ans since we don’t use SDL or any libraries like that, so we don’t feel all that comfortable working with them (as opposed to glut, freeimage, freetype, etc)

basically, we want to stay sort of low level, so we can still manipulate things and have a codebase which is readable and undersandable. Our that is that once people are up and running, they could feel free to switch to another library, such as SDL, irrlicht, ogre, juce, etc, rip out parts of OF if they want to or do whatever they want.

On linux, the only thing we are missing is video, and thanks to the hard work of grimus, we have a nice video player using FOBS and we are starting to attack the V4l / grabbing. Once that is in place, we can release a true linux port, in which all the examples compile…



I’ve just finished writing a Video 4 Linux (V4L) video capture API for openFrameworks.
V4L has been superceded by V4L2, but many devices still support it. This includes many USB cams and TV capture cards.
The webcam I tested on is the Playstation 2 EyeToy with drivers for Ubuntu. The EyeToy only supports V4L, so that’s what I’ve implemented first.

API is the same as Mac and Windows, except there is no GUI settings dialog box when calling videoSettings(); instead, settings will have to be set manually in the code.
Otherwise it supports video resizing without any problems.
I’m currently getting 15 FPS on this webcam when running the OF movieGrabberExample (see above pic). Not sure if this is device dependent, or whether I can speed it up at all.

Next, V4L2 and Firewire will have to be implemented, but for the moment I don’t have any of those devices and currently I’m dirt poor :slight_smile:

Viva le Linux!


i’m to blame for the thrown together 0.02 tarball. just checking to see if my forum account ever got authorised (if yes, spamassassin probably swallowed the email).


I’d be happy to help develop the linux version of openFrameworks,
is there any way we can synchronize with each other ?

good point maelp –

I just installed ubuntu fesity to work on getting linux up to release status, so I am very happy to form a group for this. We are looking to support Geany (IDE) and use the video solutions pierre has been working very hard on.

I made a mailing list, can I ask that anyone interested in helping with linux (or just paying attention to what is happening with OF linux) to join this mailing list –…

There is also an email-based interface for users (not administrators)
of your list; you can get info about using it by sending a message
with just the word `help’ as subject or in the body, to:

hope to see you on the list – this next week I think will be alot of activity with trying to get an official OF linux release.

thanks! zach

ps - pix, you must be authorized now. Sorry to all for the delays in authorization, the spam on the board was really crazy. We have now put in kittenauth, and there seems to be zero bots, so we went back to user authorization (we had to use admin authorization because of the number of bots that got through login)…

Hi, I’d also like to help out on the linux version of openframeworks.

I’m currently poking around the linux package you posted to see if I can get the examples to compile with code::blocks.



please check out this first “release” which is the 0.02 package based on makefiles. I will post a code::blocks version shortly:

there are still many unknowns, and it’s not completely done, I have alot of trouble with sound (but that could also just be my setup with alsa / sound card) and we need people to help out testing and documenting all the bugs and quirks.

we will post a version for code::blocks in a second. in the meantime, please check out the makefile linux 0.02.

take care!

hi all,

please check out the linux “code::blocks” package of 0.02 here, and some setup instructions for code::blocks,

any feedback is really appreciated –


Hi, I hope this helps.

I just compiled the makefile package. I compiled it in the Dyne:bolic distro and many of the examples work well in it, i just had problems with audio… maybe there was a problem with my jack server, i’m going to try them again.

After that, i ran the examples on debian and they all work except for the moviegrabber one, wich by the way didn’t work on dynebolic neither, and doesn’t even load (or maybe crashes just after loading) in any of the two distros.

…I’m new at this but i would like to help to make it fully work on linux.

hi thanks – that’s helpful news

I’m not big on linux, but the video grabber uses V4L and works in ubuntu.
Can you try to let us know where it crashes? you can put printouts throughout the code to see what call is causing the problem. do you have a v4l capable camera hooked up?


does your camera work in camorama ? I use that app to check webcams on linux.

any other linux folks have camera / v4l utility advice?