Compiling OF in raspbian Stretch


#1

Hi,

Today I give a try to compiling OF 0.9.8 in the new release raspbian stretch and it didn’t successfully compile the dependencies. It took a lot of time more than usual for a Raspberry 3 and then failed as you see in the screenshot.


Raspberry Pi Poco error
Should we move to GLFW windowing by default on Raspberry Pi?
Raspberry Pi Poco error
#2

I’m not sure OF.9.x actually supports ARMV7 for Raspbian, have you tried branch ARMV6?

You can publish all the output returned by the makefile?

Maybe you need to recompile Poco, but I’m not sure about this.

On operating systems such as: armbian ARMV7 I had a similar problem was enough to recompile Poco to solve this.

Look at the bottom of this guide, section:
Compile Poco
Compile openFrameworks

best


#3

I had tried ARMV6. I will publish later output.


#4

try using the nightlies, also as @kashim says (and i’m not 100% sure this is the case anymore with stretch) armv7 is not really compatible with raspbian. although the board uses armv7 raspbian itself is compiled for armv6 so armv7 binaries won’t be compatible

the armv7 distribution is prepated to work with archlinux for raspberry pi2


#5

I understand this problem is related to Stretch’s version of libssl which can’t compile libPoco.

I could compile the nightly version but old projects will not work since ofVec related classes have changed for glm. I was trying to make ofxPiMapper work but with no luck.

Now I’m trying to compile oF uncommenting line 926 in libs/openFrameworks/utils/ofConstants.h as stated here, the first time didn’t work but I’m giving it another go from a clean download of oF, will report if successful.

Since downgrading libssl doesn’t seem to be an option, another option will be to use an older version of Raspbian and see if I can compile 0.9.8


#6

Jessie and 0.9.8.0 works perfectly. if you want older versions raspbian are here: http://downloads.raspberrypi.org/raspbian/images/


#7

Thanks @mar.canet, I was looking for that.

I’ve just compiled nightly version of openFrameworks but when I make the graphicsExample it throws:

[notice ] ofAppEGLWindow: display(): eglSwapBuffers failed:

and I get no display.


#8

Hi Guys!

Raspbian stretch has restructured hw library (& include) path in /opt/vc folder, so you need to edit the config.linuxarmv6l.default.mk file (in OFroot/libs/OFcomplied/project/linuxarmv6l) or for paralel using with jessie make a newone eg. cp config.linuxarmv6l.default.mk config.linuxarmv6l.stretch.mk & use the PLATFORM_VARIANT=stretch in your config.make file.

change the “#raspberry pi specific” part :
# raspberry pi specific stetch !!!
PLATFORM_LIBRARIES += GLESv2_static
PLATFORM_LIBRARIES += EGL_static
PLATFORM_LIBRARIES += mmal
PLATFORM_LIBRARIES += mmal_components
PLATFORM_LIBRARIES += mmal_core
PLATFORM_LIBRARIES += mmal_util
PLATFORM_LIBRARIES += mmal_vc_client
PLATFORM_LIBRARIES += brcmOpenVG
PLATFORM_LIBRARIES += brcmWFC
PLATFORM_LIBRARIES += brcmEGL
PLATFORM_LIBRARIES += brcmGLESv2
#PLATFORM_LIBRARIES += GLESv2
PLATFORM_LIBRARIES += GLESv1_CM
#PLATFORM_LIBRARIES += EGL
PLATFORM_LIBRARIES += openmaxil
PLATFORM_LIBRARIES += bcm_host
PLATFORM_LIBRARIES += vcos
PLATFORM_LIBRARIES += vchiq_arm
PLATFORM_LIBRARIES += pcre
PLATFORM_LIBRARIES += rt
PLATFORM_LIBRARIES += X11
PLATFORM_LIBRARIES += dl

and

# Broadcom hardware interface library
PLATFORM_HEADER_SEARCH_PATHS += $(RPI_ROOT)/opt/vc/include
PLATFORM_HEADER_SEARCH_PATHS += $(RPI_ROOT)/opt/vc/include/IL
PLATFORM_HEADER_SEARCH_PATHS += $(RPI_ROOT)/opt/vc/include/EGL
PLATFORM_HEADER_SEARCH_PATHS += $(RPI_ROOT)/opt/vc/include/GLES
PLATFORM_HEADER_SEARCH_PATHS += $(RPI_ROOT)/opt/vc/include/GLES2
PLATFORM_HEADER_SEARCH_PATHS += $(RPI_ROOT)/opt/vc/include/VG
PLATFORM_HEADER_SEARCH_PATHS += $(RPI_ROOT)/opt/vc/include/WF
PLATFORM_HEADER_SEARCH_PATHS += $(RPI_ROOT)/opt/vc/include/vcinclude
PLATFORM_HEADER_SEARCH_PATHS += $(RPI_ROOT)/opt/vc/include/interface/mmal
PLATFORM_HEADER_SEARCH_PATHS += $(RPI_ROOT)/opt/vc/include/interface/vcos/pthreads
PLATFORM_HEADER_SEARCH_PATHS += $(RPI_ROOT)/opt/vc/include/interface/vmcs_host/linux

(I put some more), change lines with GLESv2 & EGL should be enough. for native build.
Worked for me (on RPI3b & raspbian stretch)
Also change lines with …/c++/4.9 lines to …/c++/6 for cross compiling

stretch use gcc 6.3 instead of 4.9.2 so recompile poco (use poco-1.8.0
has fixed the ssl >1.01 issue in stretch)
(don’t forget export or pass new CFLAGS & LIBS !!! e.g.: export CFLAGS=" … -I$(RPI_ROOT)/opt/vc/include/vcinclude" ; export LIBS="… -lGLESv2_static " etc.)

To make a gcc 6.3 cross compiler (use script “build_cross_gcc.sh” from apothecary thanks to Arturo!!!) with updated settings:

BINUTILS_VERSION=binutils-2.29
GCC_VERSION=gcc-6.3.0
LINUX_KERNEL_VERSION=linux-4.9.41
GLIBC_VERSION=glibc-2.26
MPFR_VERSION=mpfr-3.1.5
GMP_VERSION=gmp-6.1.2
MPC_VERSION=mpc-1.0.3
ISL_VERSION=isl-0.16.1
CLOOG_VERSION=cloog-0.18.1

compile OF with the new settings.
Done!
Worked for me on Ubuntu 16.04.1 & Rpi3B.
Tested with allRPIexamples(.sh). I had only one issue compiling one of shader example.
Gstreamer is also updated in stretch (from 1.4.4 -> 1.10.4)
Strech seems to 15-20% faster then jessie.


#10

Hi!

The Cross env can’t find RT audio, so add:
PLATFORM_HEADER_SEARCH_PATHS += $(SYSROOT)/usr/include/rtaudio
to the cross section of config.linuxarmv6l.stretch.mk

I prepared "buildAllRPIExamples.sh script to cross compile then run all Rpi tests on my target Rpi3B for 10 sec.
Everything works fine except some shaders with ARB extension (RPI HW limit), must correct in OF.
So this make me brave enough to give a try for the new glm feature next time.


#11

Hey did you manage to solve the .ofAppEGLWindow: display(): eglSwapBuffers failed error.

I am facing this now and looking for a solution. I started with the normal Jessie Debian too.


#12

@PiMakers
Hi, I am trying to apply your fix, the first changes in the config.linuxarmv6l.default.mk are straight forward enough, but I am not sure where to make the changes you list after that.

I don’t need a cross compiler but all of the downloadable options are broken right now and I need to get the pi up and running. It would be great if you can shed some light on this.

Cheers

Fred


#13

try disabling the opengl driver via raspi-config/advanced options.


#14

I gave up trying to get OF running on stretch as the ofxGPIO addon that I needed wouldn’t compile either. [I did get OF nightly to compile but would get the same eglSwapBuffers error].

oF Nightly works like a charm on Jessie though, I downloaded and used that instead of Jessie.


#15

There are currently two options for running openFrameworks on Raspbian Stretch. Both offer hardware accelerated EGL/GLES functionality. The first uses the “Legacy” proprietary Broadcom drivers (brcm) and the second uses the newer open source (mesa) drivers.

Method 1 (brcm) has been tested with both 2017-11-29-raspbian-stretch and 2017-11-29-raspbian-stretch-lite. Method 2 (mesa) has been tested with 2017-11-29-raspbian-stretch on the Raspberry Pi desktop.

Method 1 (brcm)

All of the steps in Method 1 can be done from Terminal (e.g. ssh) or from a Terminal within the Desktop.

Prepare your Raspberry Pi Firmware to use the “Legacy” GL drivers

  1. sudo raspi-config
    a. Advanced Options > GL Driver > “G3 Legacy” "Original non-GL desktop driver
    b. Finish and reboot.

Download and install openFrameworks (master branch)

  1. cd ~
  2. git clone --depth=1 https://github.com/openFrameworks/openFrameworks.git
  3. cd openFrameworks
  4. sudo /bin/bash scripts/linux/debian/install_dependencies.sh (sometimes you have to do this several times for it to finish correctly)
  5. sudo /bin/bash scripts/linux/debian/install_codecs.sh
  6. /bin/bash scripts/linux/download_libs.sh

Modify Your config.linuxarmv6l.default.mk File

  1. nano libs/openFrameworksCompiled/project/linuxarmv6l/config.linuxarmv6l.default.mk

Basically you just replace these three lines:

with

PLATFORM_LIBRARIES += brcmGLESv2
PLATFORM_LIBRARIES += brcmEGL

GLESv1_CM doesn’t exist anymore (for Jessie as it just pointed to GLESv2) and the older “Legacy” drivers are now prefixed with brcm (Broadcom) indicating that they are the proprietary Broadcom VideoCore blobs (which have been replaced with the newer open source mesa drivers in Stretch).

Compile a Test Project

  1. cd ~/openFrameworks/
  2. cp scripts/templates/linuxarmv6l/Makefile examples/templates/emptyExample/
  3. cd examples/templates/emptyExample/
  4. make -j2 -s
    • More than -j2 often runs out of RAM, thrashing the very slow swap.
  5. make run

Method 2 (mesa)

All of the steps in Method 1 can be done from Terminal (e.g. ssh) if a valid DISPLAY env. variable is set or simply from a Terminal within the Desktop.

Prepare your Raspberry Pi Firmware to use the “Legacy” GL drivers

  1. sudo raspi-config
    a. Advanced Options > GL Driver > “G1 GL (Full KMS) OpenGL desktop driver with full KMS”
    b. Finish and reboot.

Download and install openFrameworks (master branch)

  1. cd ~
  2. git clone --depth=1 https://github.com/openFrameworks/openFrameworks.git
  3. cd openFrameworks
  4. sudo /bin/bash scripts/linux/debian/install_dependencies.sh (sometimes you have to do this several times for it to finish correctly)
  5. sudo /bin/bash scripts/linux/debian/install_codecs.sh
  6. /bin/bash scripts/linux/download_libs.sh

Modify Your ofAppEGLWindow.cpp File

  1. nano libs/openFrameworks/app/ofAppEGLWindow.cpp

Basically you just delete these six lines:

As you can see, we’ve been waiting for this day!

Compile a Test Project

  1. cd ~/openFrameworks/
  2. cp scripts/templates/linuxarmv6l/Makefile examples/templates/emptyExample/
  3. cd examples/templates/emptyExample/
  4. make -j2 -s
    • More than -j2 often runs out of RAM, thrashing the very slow swap.
  5. make run

The Future

Now that the mesa drivers are available, we might consider moving to GLFW for Raspberry Pi (the windowing system we use on all other desktop platforms) if the performance doesn’t suffer. GLFW supports the newer mesa drivers. We need a volunteer to do some performance testing. If the performance is equal, the choice to switch to GLFW should be obvious. If not, then we should have a conversation!


Raspberry x11 window
ofxCv compiling issues on Raspberry Pi (Raspbian stretch)
Setting up Raspberry Pi 3 B with OpenFrameworks
Attempting to make ofxPostProcessing on Raspbian
Project Generator support on rPi? Poco linker errors on nightly build
#16

Does Method 2 require the Desktop environment to be enabled?


#17

I have not tested Method 2 without the desktop yet – it’s creating an X11 window, so I’m assuming it needs some kind of x11 context. The ofAppEGLWindow checks to see if the DISPLAY environmental variable is set and then proceeds to use X11 (XCreateWindow, XDestroyWindow, etc), otherwise it tries to use dispmanx*.

In my experience so far, mixing the two methods doesn’t work (not to say that we have to use X11 to create a window … we could probably somehow use dispmanx to create the EGL context and still use the mesa drivers). Just haven’t tried it.


#18

Tried your methode 2 but still wasn’t successfull.
Now I get a Window but still the notice :
ofAppEGLWindow: display(): eglSwapBuffers failed:
and some errors before.

This was the 3DPrimitives Example nit the
eglSwapBuffers fail notice appears even on the emptyExample


[notice ] ofAppEGLWindow: createSurface(): setting up EGL Display
[notice ] ofAppEGLWindow: createSurface(): EGL Display correctly set 0xe34258
libEGL warning: DRI2: failed to authenticate
[notice ] ofAppEGLWindow: createSurface(): no current renderer selected
[notice ] ofAppEGLWindow: createSurface(): default renderer detected
[ error ] ofAppEGLWindow: createSurface(): no matching configs were found, num_configs: 0
[ error ] ofAppEGLWindow: setupPeripherals(): peripherals not supported on X11
[notice ] ofGstVideoGrabber: Probing devices with udev…
[ error ] ofGstVideoGrabber: initGrabber(): no devices found, exiting without initializing
[notice ] ofAppEGLWindow: display(): eglSwapBuffers failed:

Got an Raspberry 1 with the Rasbian Stretch OS
Linux raspberrypi 4.9.59+ #1047 Sun Oct 29 11:47:19 GMT 2017 armv61 GNU/Linux

Does any one have any further ideas?

In the meantime ill try method #1


#19

If you’re using an RPI 1, double check to make sure you have enough GPU memory allocated. Did it work with method 1?


#20

I tried your method 1 and this one worked for me.
Thanks.
Is the GL Driver so much better ?
Do you think it would make sense going
on to try method 2?


#21

The main reason the Method 2 will be good in the future is that it will be easier to maintain for openFrameworks since we can just use a normal desktop windowing system (e.g. GLFW). I’m not sure if RPi has any plans to stop supporting the brcm drivers, but since they are now referred to as legacy drivers, I’d guess that the future is in the open-source mesa drivers.

I don’t foresee any significant performance differences, but we need more rigorous testing to compare the two (e.g. is it possible to run openFrameworks applications on the “lite” version of Raspbian using the mesa drivers?).

Practically, I’m probably sticking with method 1 for now since it’s the status quo for oF since we got oF running on the RPI 5 years ago.