Make headless Processing work on Heroku!

gistfile1.md

I need to run the virtual frame server Xvfb on Heroku. We need this to fake a display on a server that doesn't have one, as the Java Applet class relies on a display.

To run an arbitrary binary on Heroku, the binary need to be compiled as a static linked binary, with all the dependencies bundled with the binary. This is because we can't just run apt-get on Heroku, like on any other normal server.

I've tried to compile as a static binary via Vulcan (https://github.com/heroku/vulcan), but the binary still ends up as a dynamic linked binary that relies on dependencies installed on the OS.

I've tried to compile it on a local Linux like explained here: http://bindle.me/blog/index.php/405/running-binaries-on-heroku But it still ends up as a dynamic linked binary.

This is my question on Stackoverflow: http://stackoverflow.com/questions/14845291/compile-static-linked-binary-of-xvfb

I'd be open to other suggestions, like using another fake display server, or use a fake implementation of Java AWT (which I've stumbled upon a few times). Whatever gets Processing to think there's a display on a server that doesn't have it.

This is the app I want to make work: https://github.com/runemadsen/processing-sinatra

If you install virtual box and vagrant, you can see it working on a local Linux.

have you tried:

export LDFLAGS=-Wl,-Bstatic;./configure --enable-shared=no

or

export LDFLAGS=-static;./configure --enable-shared=no

even with that making something run from one version to another in linux will be problematic so you probably want to be sure that the platform you are compiling on has the same versions of some basic libraries like libc... (probably using vulcan)

Thanks @arturoc. I tried -static, but let me give the first line a whirl.

@arturoc. Tried this:

$ sudo apt-get build-dep xvfb
$ apt-get source xvfb
$ cd xorg-source
$ export LDFLAGS=-Wl,-Bstatic;./configure --enable-shared=no
$ vagrant@lucid64:/tmp/xorg-server-1.7.6$ find -iname Xvfb -type f -exec file {} \;
  ./hw/vfb/Xvfb: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.15, not stripped

As you can see, I end up with a dynamically linked binary. Anything I'm doing wrong here?

The other line gave me an error saying that the C compiler can't compile executable binaries.

While you can't apt-get, you can usually use debs, see here for an example.

@runemadsen --enable-shared has to do with building shared libraries. It shouldn't have any effect on how executables are linked (i.e. it's not what you want)

@runemadsen I answered your question on stackoverflow

@dpippy @mdz I'll dive into it right away.I'll update the gist as it progresses. Thanks so much! Really appreciate it.

@dpiddy As it's probably clever to do this in a buildpack, that inline buildpack is a graet reference.

I'm stuck at a ./configure command that is not recognizing my packages, even though I'm downloading them, unpacking them, and adding the correct flags:

https://github.com/runemadsen/xvfb-buildpack/blob/master/bin/compile

I'm still getting:

No package 'glproto' found
No package 'gl' found

Anyway, I'll try to see if I can figure it out.

@runemadsen those errors are from pkg-config telling you it can't find the *.pc files. You can tell it where to look with PKG_CONFIG_PATH, but it probably won't help as the paths inside them won't match the directory structure you're unpacking them into. .debs are unfortunately not designed to be relocatable.

Thanks @mdz. Oh, the joy of compiling.

Whatever happened to headless processing on Heroku?