You should just be able to just remove those flags, they are not needed. They enable all posible optimizations for your machine which will not work when porting to an older cpu.
We should probably remove them by default since they make compatibility harder.
If you want to send a PR that would be really useful
Thank you @arturo do you think is better to remove or to use a generic one like x86-64 ?
@mr.Bitmap if i understand you correctly i think you are mixing things, changing the flag will not make it work in a os where the dependecies are not installedā¦
removing them is fine, itās what iāve used when working with small or older machines in installations. the compiler will set a default one that is the most generic and will work without problem on any x86_64
ok, will do it on monday, thank you
What is PR? I googled the possible shortcuts, but given the context I guess youāre talking about a pull request. Can I do it from the forum here somehow? I donāt have a GitHub account yet. Havenāt done this beforeā¦
Does the same apply for Windows that these compiler flags can be removed (or commented out) to run on othersā computers without problem? That might explain why old of_0.7.3 compiled projects worked on other computers, but 0.10 and 0.11 didnātā¦
Can you remember by any chance - can it be that the flags were added into newer OF releases and in the old versions back when Code::Blocks were used, it was without these flags?
Maybe i can helpā¦
Yes PR is a pull requestā¦ to a github repo that has to be done with a github account.
Those flags make the compiler to use especial instructions that sometimes are only available to some models of cpu, removing those will make the compiler to set a common safe flag and that will make the binary to not use special functions available in specific models of CPU and then be more compatible. Using native is like saying the compiler, eh use all the ātricksā available in my cpu to optimize the binaryā¦ but sometimes those ātricksā are not available in others cpus
But you will allways need to install the oF dependecies.
Those flags are used in windows when you compile with msys so the discussion does apply to that situation, but not for example when you compile with visual studio.
P.D dont remember what building system was used in codeblocks
P.D. Just take a look at your game and drawings are great!! i like it
Thank you 
, itās just a demo, and Iām currently working on a full version that is supposed to be drastically changed considering some game mechanics and UIā¦
Not so for Windows. I actually managed to make the Windows build from msys2 that runs on PCs without OF dependencies installed - by changing -march=native to -march=i686. Thatās why my game can be run on othersā computers without having OF installed.
I seek the same for Linux, but thatās apparently not easily achieved.
@coding suggested I could use .AppImage to make Linux support to run out of the box, but no one in the forum has yet managed to make such a build as easy it is for Windows (msys2 ming32 only) and Mac OS - just build and run everywhere.
Iāll need to copy .so libraries to package with the OF app somehow (AppImage already does that by redirecting the libs from the system to itself, tried to copy them one by one, but havenāt managed to run it elsewhere - like on fresh Linux Live environment)
Windows with msys2 has it easy - only make & make copy_dlls and there you goā¦ Now an alternative to copy_dlls for Linux (either universally via AppImage or separately as packages for different distros)
Come on, Linux OF, we can make it together somehow. If programs like GIMP, Krita, many many others can be downloaded and installed for target Linux OSes, there should be a way for programs developed in OF (without the procedures like ./install dependencies, ./install codecs and compileOF)ā¦
Im not super experienced on windows but i allways needed to install c++ redistributable to make an of app to runā¦
I tried to make an appimage following a post here in the forum and it works in the point that you dont need to install of dependecies but i was not able to make it work across diferent os versions, im sure that i was not doing it correctly.
Why dont you do a installer package? seems like a good solution.
I donāt do software to release to masive public so not an expert but you will not find any reference in the documentation relative to the fact that changing that flag will make it a binary do not need for external dependencies. only that it will use instructions more or less common
https://wiki.gentoo.org/wiki/GCC_optimization#-march
That might just be the right idea. I found out you donāt actually have to run all dependencies script, just install all the needed libraries that will add shared objects (.so) into your system libs folder.
I mostly make Fedora builds cos Iām on Fedora 32 currently now, but I also have notebook with Debian 10, where I also have OF installed.
Just tried to boot into live environments and make some my OF apps run on Fedora 32 fresh live environment (the same as my computer but without OF installs) as well as former version Fedora 31 (Live).
Most of the dependencies were not required, only had to install:
But that may be because these OF apps of mine do not use any fancy OF stuff, like openCV, or some audio/video analysersā¦ For every separate OF app, you would just install the ones that are actually used by your app.
After that, it ran out of the box on Live Linux environment. Nice - Fedora is accounted for, and I guess (and hope) same applies for similar distro like Red Hat or CentOS (even openSUSE can use dnf that is used to install these dependencies in Fedora version of OF, so hopefully openSUSE is similar to Fedora in these regardsā¦ )
I also have a Live CD with Ubuntu 18.04 LTS (I know itās olderā¦ whatever), tried to boot it and install these same dependencies with apt-get install (these are the main differences to run scripts of OF dependencies for many linux platforms - the different package manager). Though it couldnāt find them at first - I had to run such commands as: sudo add-apt-repository universe and sudo apt update prior to this.
(note: libGLEW.so had to be linked to libGLEW.so.2.1) via:
sudo ln -s /usr/lib/x86_64-linux-gnu/libGLEW.so /usr/lib/x86_64-linux-gnu/libGLEW.so.2.1
(note: libboost_filesystem.so. had to be linked to libboost_filesystem.so.1.69.0) via:
sudo ln -s /usr/lib/x86_64-linux-gnu/libboost_filesystem.so /usr/lib/x86_64-linux-gnu/libboost_filesystem.so.1.69.0
This time, dependencies were all accounted for, except:
Turns out my Fedora build has more recent GLIBCXX version for Ubuntu/Debian distros and these other two (libpthread.so.0: version āGLIBC_2.30ā and libm.so.6: version āGLIBC_2.29ā ) are another problem that canāt be solved by just installing something else.
But that may be because I tried to run Fedora/RedHat/CentOS compiled OF app run on Ubuntu/Debian system.
Hope that if I make a Debian 10 build, it will run on both Debian and Ubuntu (after these few libraries installed)ā¦
Hi everyone ! I arrived to this post by chance (the title is a bit generic) and it was very useful since I was trying to generate an AppImage for our software based on openFrameworks (http://audiostellar.xyz)
I havenāt been able to make it work in all platforms and I thought it was because of the AppImage but after reading this I changed the binaries to debug and now it works for the people that it wasnāt.
I also modified of_v0.11.0_linux64gcc6_release/libs/openFrameworksCompiled/project/makefileCommon/config.linux.common.mk commenting the march=native line and rebuilded the project using make clean && make, read the output and it was defintely recompiling openFrameworks but the binary still wasnāt working for these people (but debug was) so I guess something else is missing.
Besides the bigger filesize, is distributing the debug version a terrible idea ?
Iād like to contribute with my working AppDir if anyone is interested, changing the binaries and the .desktop should work for any openFramework app.
Thanks !
Leandro.
Hi @macramole
You shoud comment those two lines and try, i will try to find a moment and do the PR:
PLATFORM_CFLAGS += -march=native
PLATFORM_CFLAGS += -mtune=native
Im interested in the AppImage approach but at least for me, is better if you wrote a small post telling how to do it.
Last time i tried Appimage did not work across versions distributions, if i did it on 18.04 will not work on 20.04 and viceversa.
@pandereto Iām not using msys2 so Iām just modifying config.linux.common.mk as @mr.Bitmap posted:
Regarding the AppImage, the AppDir is a directory where you put the bins and the libraries needed, the structure is like a linux system. The tricky part is what libs to put there because not only you may be missing a few but you can also may be putting too many that causes not to work. Once you have this, a simple script will convert it to AppImage and thatās it.
I made the AppImage using 18.04 and it is working for 20.04, also Manjaro, Debian 10 and even Kali linux.
Sadly I havenāt documented my whole process correctly, but I used https://github.com/AppImageCrafters/appimage-builder that helped me in the process of gathering the correct libraries. This was very tedious as a lot of trial and error was needed. Also, the creator of that app kindly helped through IRC. Thatās why Iām offering the AppDir already done so only the binaries needs the be changed.
A wonderful step! Thanks for your insight. I actually managed to make such Debian 10 build that would run also on Ubuntu 18.04, Fedora 31 and Fedora 32 (purely usb/cd-booted live environments) with installing the required .so libraries.
It was better than making my recent Fedora version build, because it uses older GLIBCXX version, thus making it compatible with both older and newer Linux versionsā¦
ldd command is very helpful here, because sometimes you have to create a link of .so library file you already have to the one required by your OF app (the filename must match: if ldd requires libboost_filesystem.so.1.67.0, and you have only libboost_filesystem.so in the system, you make a link named: libboost_filesystem.so.1.67.0 that points into what you already have there.)
In case of Ubuntu (running Debian-compiled OF app), I had to make three linkages:
#note: libGLEW.so has to be linked to libGLEW.so.2.1 via:
sudo ln -s /usr/lib/x86_64-linux-gnu/libGLEW.so /usr/lib/x86_64-linux-gnu/libGLEW.so.2.1
#note: libboost_filesystem.so has to be linked to libboost_filesystem.so.1.67.0 via:
sudo ln -s /usr/lib/x86_64-linux-gnu/libboost_filesystem.so /usr/lib/x86_64-linux-gnu/libboost_filesystem.so.1.67.0
#note: libboost_filesystem.so.1.67.0 has to be linked to libboost_system.so.1.67.0 via:
sudo ln -s /usr/lib/x86_64-linux-gnu/libboost_filesystem.so.1.67.0 /usr/lib/x86_64-linux-gnu/libboost_system.so.1.67.0
Oddly enough, Debian compilation separated libboost_filesystem.so and libboost_system.so, where it should be the same (I guess?), so they are both eventually linked into one file in Ubuntu (libboost_filesystem.so that is present in the system structure).
I took notes so each Linux distro could have separate installation script.
Debian/Ubuntu would have:
sudo add-apt-repository universe
#update it
sudo apt update
#pass the apt-get install dependency packages
sudo apt-get install libopenal-dev libglfw3-dev librtaudio-dev libglew-dev libfreeimage-dev libboost-filesystem-dev liburiparser-dev libcurl4-openssl-dev
and then the linking of the files I mentioned aboveā¦
Fedora would have:
dnf install glfw-devel glew-devel freeimage-devel boost-devel uriparser-devel curl-devel
#make link of libboost_filesystem.so to libboost_filesystem.so.1.67.0 (the name is because of debian build)
sudo ln -s /usr/lib64/libboost_filesystem.so /usr/lib64/libboost_filesystem.so.1.67.0
sudo ln -s /usr/lib64/libboost_system.so /usr/lib64/libboost_system.so.1.67.0
If I understand it correctly, AppDir should have these resolved internally and linked into itself as though it was taking the ldds from the system (in this scenario, the .so files in AppDir are accessed instead of system, thus making it work on all Linux distros).
Thank you for providing your AudioStellar AppImage. Downloaded it (took a look - itās a cool app ), and will take inspiration from the package structure how to compose it the way that should work.
@mr.Bitmap, Iāll upload version 1.0 soon, the AppDir structure is the same so it will be useful as is, the only difference is that I will be distributing the debug binaries since they are working fine in all systems.
Do you guys think we will experience any performance issues because of releasing the debug binaries ?
Thanks !
It seems to me that I have usually not noticed performance issues with OF debug binaries, except/unless there is some bottleneck that is affected, which I have seen happen with programs that are doing a lot per call to Update and/or Draw. Like when I try a 500-ship space combatā¦ and then itās because of the clumsy hit detection I have in my own code.
@macramole would you still be able to share this? Iāve had a go at this before and itās a very tedious process, and I didnāt get it to work. Iāve been meaning to have another go, but yeah it was time consuming so Iāve not got around to it.
I for one would very much appreciate an starting point to work from. If it works well I might contribute some documentation and look into getting the release builds fixed.
Regarding debug mode, I canāt say I ever really notice the difference in terms of performance (and Iām almost always running in debug mode), but I wouldnāt be surprised if thereās a small performance hit that goes unnoticed due to the extra symbols being read. In any case itās almost negligible.
Hi @grimus,
I think the easiest way to go is to download my AppImage from http://audiostellar.xyz/ . Then:
Of course you may want to edit the .desktop file and png from /usr/share/ so your application doesnāt read āAudioStellarā
Remember Iām using the debug build, otherwise it wonāt work in a lot of other systems
I agree the process is tedious and time consuming thatās why I want to share it.
Let me know if it worked 
Excellent thanks, will give this a try and get back to you!
@macramole it worksā¦at least I tested on Ubuntu 20.04 and had no problems. I tried another app but it failed because it needed OpenCV, which should be easy to add to the AppImage.
I cannot thank you enough for this, if this works on enough systems this is huge! Iāll also be able to build on this for sure. Iāll probably eventually clean it up and put it on Github or some other repo, for others to use (and include instructions)
<3 <3 <3
Oh by the way, I had no problems with Release mode, at least not for the moment. I built my apps with qtCreator FWIW. What systems did it not work on?
Oh thatās good news, Iām glad it worked. Let us know what needs to be added for OpenCV
Using release mode didnāt work on older systems, Iām using an 8th gen intel CPU and it didnāt work on 3rd gen or so. I use qtCreator as well