Linux problem please help [solved]

************** SOLUTION *********************
As arturo commented remove -march and -mtune flags from config.linux.common.mk, recompile oF again and you are ready to go


Hello

I use ubuntu (xubuntu) to develop in oF, works great but now i need to move my app to the installation machine.

The installation machine has the same ubuntu version 20.04.1 i installed the oF dependencies on this machine but all the apps i try get a core dump error… even a empty example get a core dump.

To discard a problem with my app i do the test with an empty app that works great in the develop machine but not on installation machine where i get a core dump error.

To put even more extrange it runs on debug.

So in resume, a empty app that works on dev machine gives a core dump error on installation machine only in relase, it works on debug.

I tried: two different installation machines, clean build and rebuilding app, fresh xubuntu install… also tried to compile a sample on another develop machine and is the same

Does someone has a clue?? Is the first time i see something like this.

I know… it sounds wreid

Thanks!

1 Like

Hi.
Same hardware on both machines? Maybe there’s some problem with video driver/openGL version?
On installation machine can you compile examples shipped with OF install?

Thank you

Hardware is different, i checked opengl version, is not the first time i used the installation machine model and never had an issue.

I checked with ldd the release and debug version of a empty example and found the same libs… so not sure why debug works and release not.

Yes i can compile a sample and it runs on debug/release in the installation machine.

You have copied just source file or the whole project? Maybe the optimization flags (those used to compile in release mode) are conflicting with second machine hardware

can you compile it on installation machine? are both machines using the same processor architecture?

Yes i can compile on installation machine.

Both machine are same arquitecture, also please note that a compiled app in debug works, is only release that do not work. Both are intel nucs, dev is i5 and installation is a celeron

We can discard:

  • code: as empty example is able to reproduce problem
  • dependencies: i installed the install_dependencies and codecs
  • same OS version
  • hardware tested on two different installation machines, and code compiled on two dev machines

if i compile same empty example on installation machine it works and when do ldd to view libraries i see the same libs as the app compiled in dev machine that do not work

Thank you!

If in debug mode work and in release not, as far as i know, the only differences should be the optimization flags (-O3 -march=native -mtune=native) and debug flag (-DNDEBUG or -DDEBUG).
The latter should be used for blocks like

#ifdef DEBUG
//code executed only in debug mode
#endif

You can try disabling the optimizations flags modifying the makefile (or whatever system you’re using), or you’ll have to debug your apps to find where it breaks…

HTH

1 Like

Thank you Bencilari

But it happens with a empty example… no custom code, just a blank empty example

This is interesting and maybe the cause, my dev machine is a old i5 5 generation and the installation machine is a celeron N3350…

Found this on stack-overflow, where they basically say that -march flag is rarely used because of compatibility

-march=native is a destructive flag. It makes the binary possible not compatible on a lot of hardware (basically any CPU that is not a direct descendent of the one used for compilation). It is simply too dangerous to enable this by default.

2 Likes

Definitely! And I can relate to that… Wondering why my OF app wouldn’t run when compiled using msys2 mingw32 on others’ PCs than mine (but rarely on some yes), a member of GameJolt actually helped me track and troubleshoot to this problem…

linking my post where @coding asked me how did I manage to run it on others’ PCs without installing OF per each computer. Well, turns out I had to change -march=native to -march=i686 to run compatibly with all 32-bit (and thus also 64-bit) Windows systems…

Now, this one is windows version (I also use a linux one though…), but you get the idea…

@mr.Bitmap Did you opened an issue on github?

In linux seems you get a core dump with no clues to see what happens…

I can not confirm that this is the cause until monday but im almost sure is the cause to my problem. If is not opened i will do, im not saying that this flag has to be removed but if no removed it should be a warning somewhere…

It has been my headache for two days :slight_smile:

-march=native essentialy means “built only for your CPU where you actually made the build” and thus it’s not expected to work on other machines, whereas i686 means 32-bit. 32-bit being compatible in 64-bit, but not vice-versa.

Nope, haven’t done this before, but maybe I should? I don’t know if this is actually a serious issue if it can be edited in compiler flags, but sure, there could be an option to alter it for you automatically if you’re unaware of it, or just have everywhere:
-march=i686
-mtune=i686

for maximum compatibility.

Linux is a different beast… I have Fedora, but used Ubuntu before, and even have a notebook with Debian. Both Fedora and Debian make nice builds for me via terminal.

I dont know what need to be considered “official serious” but it was enough to make me spend lots of time… checking lib versions, gpu drivers, opengl version… etc etc etc

Im not expert so not sure if is best to remove the march and tune flag, or put another value as you pointed. But if not removed or changed i think a note somewhere must be useful to others!!!

I think at least is something to be considered

You’re using Ubuntu, right? Maybe there’s something with this distro. I wonder if that’s still the case, but in 2019 when I used Ubuntu, I remember @arturo mentioning that linux OF version from the main download page had some bugs, and that I should download some from the nightly builds… And I remember that one such nightly build OF 0.10 (back then) worked…

Morever, is Xubuntu a Ubuntu derivative OS, or just Ubuntu with XFCE? Cos when you’re using derivative linux distro, there’s some other step to take when configuring OF for linux…

Yep im on xubuntu,ubuntu with xfce, but that flag is applied to all distros so is a common problem.

I used it a lot and never an issue, but this time i was developing/installing on a newer combination that seems to be affected. Previously i moved the binary between intel nucs with xubuntu without problem. I have the same OS on all my computers… im happy with that, very low ram and cpu usage so i can use a low end rugged cheap celeron nuc

Also used Appimages but was never be able to make it work across versions, i mean i create on 18 and it works on all the computers i tested on 18 but not on 20… so i stopped using it and began to just pass the binary and installing the oF dependecies on the machine.

You might try a new OF installation from a nightly linux build of OF…
https://openframeworks.cc/download/

linux64gcc6_nightly.tar.gz
linux64gcc5_nightly.tar.gz

or

linux64gcc4_nightly.tar.gz

(respectively to your gcc version)
below in the link, copy your OF project there and build from it, and see if that changes anything…

I don’t think it will change anything as the flag will be still there…

  • It happens on a empty example so is not caused by custom code
  • works in debug but not in release and as Bencilari say the only difference is those flags
  • works between all my other intel nucs (very close hardware)
  • compiling on the target machine works so not a hardware problem, compatible gpu… etc

So it must be something related to those flags and the cpu differences… i will test on monday and if that is the cause i will post it on github so at least when someone have the same problem again it will find a github issue and hopefully will solve the issue

Sure arturo knows about!!!

I wonder if changing all -march=native to -march=i686 solve anything. Your post made me look into my OF linux folder and I grepped for all files that could have -march=native inside and changed them into i686…

I also have this annoying problem that my Linux OF apps won’t run anywhere else than my system - without installed OF dependencies, thus your linux-built OF apps wouldn’t run for other people (tested with virtual machine), but if that worked for Windows, who knows… it might work for linux as well? Hope linux can accept forced 32-bit everywhere, as it’s the most compatible…

Per docs:

https://gcc.gnu.org/onlinedocs/gcc/x86-Options.html

i686’ When used with -march, the Pentium Pro instruction set is used, so the code runs on all i686 family chips. When used with -mtune, it has the same meaning as ‘generic’.

native’ This selects the CPU to generate code for at compilation time by determining the processor type of the compiling machine. Using -march=native enables all instruction subsets supported by the local machine (hence the result might not run on different machines). Using -mtune=native produces code optimized for the local machine under the constraints of the selected instruction set.

is advised that using native might cause lack of compatibility

My dev machine i5 sets flag as

‘broadwell’ Intel Broadwell CPU with 64-bit extensions, MOVBE, MMX, SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, POPCNT, AVX, AVX2, AES, PCLMUL, FSGSBASE, RDRND, FMA, BMI, BMI2, F16C, RDSEED, ADCX and PREFETCHW instruction set support.

While celeron is set as

‘goldmont’ Intel Goldmont CPU with 64-bit extensions, MOVBE, MMX, SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, POPCNT, AES, PCLMUL, RDRND, XSAVE, XSAVEOPT and FSGSBASE instruction set support.

1 Like

Aaah, thanks… I was actually looking for this… tried to google compiler flags but didn’t find this extensive list.
Ok, so it is decided for me:

-march=x86-64 (as most compatible both 32/64bit machine architecture)

and

-mtune=generic (hardware agnostic, we don’t know what cpu will people use to run our OF apps)

Actually, I modified of_v0.11.0_linux64gcc6_release/libs/openFrameworksCompiled/project/makefileCommon/config.linux.common.mk to this (starting with line 201):

ifndef PROJECT_OPTIMIZATION_CFLAGS_RELEASE
	# RELEASE Debugging options (http://gcc.gnu.org/onlinedocs/gcc/Debugging-Options.html)
	PLATFORM_OPTIMIZATION_CFLAGS_RELEASE = -O3

	ifneq ($(LINUX_ARM),1)
		PLATFORM_OPTIMIZATION_CFLAGS_RELEASE += -march=x86-64 -mtune=generic
	endif
else
	PLATFORM_OPTIMIZATION_CFLAGS_RELEASE = $(PROJECT_OPTIMIZATION_CFLAGS_RELEASE)
endif

, deleted openFrameworksCompiled/lib/linux64/obj folder as well as libopenFrameworks.a and let it build anew with building one of my OF projects…

Nice, it remarkably compiled successfully :+1:, whereas when I tried i686, the make output was giving errors in the middle of build and couldn’t complete.
Ok, this x86-64 with generic tuning worked, now only to test it via virtual machines… (Never before was able to run compiled linux OF app on other linux without installed dependencies, so we’ll see…)