Upgrade to openFrameworks 0.10.1 #20
Comments
|
actually I did the upgrade few weeks ago |
|
I also added a new Basically I did what @MatthewScholefield describes : updating the source file with the ones from of 0.10.1 release then updating *.cmake with the new source and dependencies. |
|
So great to see this, thanks @avilleret - I'm also running 18.04 and have been following your guide how to create sysroot, though not managed yet. First thing is there seem to be issues with the libraries: zlibg1-dev - misspelt, should be zlib1g-dev? Then once steps are complete I try a build: Have tried adding |
|
Silly mistake - libs were already installed so aptitude would skip over them - solution is to use "reinstall" alongside "install" to ensure everything is present: Now getting an error for boost libraries though, all seem to be present |
|
thanks @autr for the review, could you send a PR for the lib list update ? concerning install vs reinstall for aptitude, I think we should do both concerning boost, I always have trouble finding it when cross compiling btw I fixed the build under ArchLinux |
|
concerning boost, I have the following (from my sysroot folder) 👍 and CMake finds it right : could you check @autr if you have the same tree for boost ? |
|
btw, I just removed glew source from repo to use system's one |
|
@autr concerning Boost, I do have issue when including 3rdparty lib that needs come with their own boost version, then boost_dir is overridden and openframeworks can't find boost_system and boost_file_system lib. Do you have such a thing on your side ? |
|
Hey @avilleret - starting anew with Trashed sysroot and installed without - but on Ubuntu 18.04 machine, glew doesn't seem to be present so installed w. Can you tell me how to link system glew into the Cmake config? |
|
Ah, I see the update is to add glew into the sysroot. This is the error I get on Ubuntu side: |
|
hum strange that it search for OpenGL library since on arm it should use openGLES anyhow, libGL.so is in libgl1-mesa-glx package btw, I put my sysroot here if you want to check it out : https://www.dropbox.com/s/wdloxqutn4b64mu/sysroot-of0.10.tar.gz but I'm currently testing ofnode on RPi and it doesn't work yet |
|
@autr I confirm that CMake should not search for GLEW when building for RaspberryPi |
|
Hi @avilleret - update on attempt:
Is there something I should be doing with regards to Arch / Arm7? I was building my sysroot from Stretch (Arm6) but for these attempts was using your sysroot tar. |
strange, the former always works for me (but the later does too)
I also noted that but forgot to push it, it's up-to-date now (btw I just replaced the
could you post the error ? thanks for the feedback |
|
Thanks - I saw some strange behaviour with ofGLFWWindowSettings still being seen even after I had Here's the full error I'm now getting: |
|
ok, first thing, you're using GCC 7.3.0 and I have 8.2.0 from here https://github.com/abhiTronix/raspberry-pi-cross-compilers this will help a little bit concerning the missing lib, those are 3rd party lib depencies that are not satisfied I put a script in my sysroot to install .deb files into the sysroot |
|
hopefully, everyone is sleeping so the WIFI hostel is very fast tonight, here is my updated sysroot : https://www.dropbox.com/s/koekcmmpw00sews/sysroot-ofnode_0.10.tar.gz |
|
Sorry for the late reply!
Here's the output: Is there something to be added to |
|
Success! Silly mistake - I needed to name the GCC dir correctly to Will this run on Stretch if armv7 or should I install Arch for testing? |
|
Any idea why the executable can't find its libraries? It seems to be added correctly during the build process. |
hum... when linking dynamically to openFrameworks, you should have copied the libopenFrameworks.so to your Raspberry Pi for example, to put it in an you can now copy the install folder to your raspberry pi |
|
Sorry if I find this quite confusing - my understanding is that a compiled app contains all its libraries / binaries needed to run. Is a dynamic library something that can be placed elsewhere / outside of the app - in this case the compiled libopenFrameworks.so? At the moment I am trashing and building from scratch with the latest 0.10 branch like so: At what stage and how should I add the libopenFrameworks.so relative to the path of the compiled app? And is it a relative or absolute path? I have OF 0.10 compiled on the Pi also, so is there a location within the OF folder that would reference libopenFrameworks.so? Thanks! |
|
OK, working! 🙌 Just did: I will try rebuilding the sysroot from scratch with a fresh install of Raspbian because I'd like to help update the sysroot guide. Is what's there correct before I start? Thanks again! |
|
Does the install method add the libraries statically or install them to a certain location? |
If an executable depends on a method that is implemented in another library it needs to be linked to that library. It can be link either dynamically or statically. When linking statically the library is copied into the executable binary and then it doesn't depend on an external library. Then during the install step the libopenFrameworks.so is copied in the lib folder and the data folder is copied next to the binary.
linking statically could fine in some way, but sometimes it's not allowed by the library licence, or no static version of the library exist. |
|
OK, thanks for explaining. I'm still unsure how to perform the install step however - is the install dir made in the ofApp or build-of-ofApp folder? And should the flag be added to the initial generation of CMake files? Another question is Addon usage - I tried for example compiling the ofxOMXPlayer examples (both V2 and original ) but without success. Inside the openFrameworks.cmake there seem to be conditionals for different addons - so is it then a limitation of the cmake approach that Addons need additional configuration? ie. Ninja interprets differently to Make? |
the application is installed where you want, and you define it with
Concerning the addon, there is a CMake function called |
|
OK thanks for the clarification. For these purposes I’m using make system as I believe its also what’s used for CI and test builds over here. Re. OMXPlayer examples - it has dependencies - so my assumption is that this would necessitate a rebuild of the sysroot? In which case would it not also be possible instead to use a live mounted Pi via Samba as outlined in the cross-compile guide here. Re. a local sysroot build, this is the process I’m attempting in mind of creating a bash install script. From PiFrom UbuntuBuild OF and ofApp exampleSuccess Success Build example-basic from OMXPlayer v2Same example builds correctly from RPI, but not via CMake method: Error: In file included from /media/psf/gilbertsinnott/ofnode/build-omx/cotire/ofApp_CXX_prefix.cxx:8, |
not a rebuild, but an update yes, iirc you need libavfilter-dev at least (which is not needed by of itself)
this is of course feasible but way slower than having it on a local SSD. The easiest way to make a sysroot is to build of from scratch on RPi (and this install all needed libraries) and then copy the sd card to your computer. This is quite easy but you'll end up with a huge amount of unneeded things. My current workflow is :
concerning ofxOMXPlayer I'm using it, but I didn't build example yet, though it's planned for this afternoon |
|
concerning ofxOMXPlayer, there are couple of things to tweak and concerning the CMakelists.txt here is mine : |
|
Fantastic, thanks for the clarification ... for ease, at the moment I'm using RPI_ROOT as outlined in the guide for 0.9.8 - as it's also useful for testing this method and the Travis / CI scripts in the OF main repo. OF examples are compiling fine, but the example-basic from your fork of ofxOMXPlayer is returning;
Might I need to update the symlinks for the dependencies in the RPI_ROOT ? |
|
I tried to use this fork to integrate it in a Conan architecture (where switching to 0.10 to avoid the OpenSSL issue mattered) and managed to get most of the CMake working, however it seems that something is missing: there isn't any There seems to be some install rules in a macro in the file openFrameworks.cmake but they are never called when building the library. |
Someone asked about upgrading openFrameworks so I decided to create an issue here to do it. There currently isn't a clear process for how to upgrade this library, so we can try to develop one by documenting the problems we face while trying to do it. So far, here is the best idea of how to start:
src/openframeworkswithlibs/openFrameworks/inside the.tar.gzof the latest releaseThe text was updated successfully, but these errors were encountered: