Try and make things more organized by creating a project to add in issues, this makes it easier to search for just FreeBSD issues. Also this opens doors to other users who enjoy using FreeBSD want to make E better.
Mon, Apr 15
Thank you Peter! Enlightenment really rox! Just as my beloved FreeBSD! This is something really really new and the design is simply amazing.. really reminds me of the old good Unix or even Amiga times! :-)
cederom, you should begin with full uninstall E and EFL, port version of EFL is really outdated. Then you should download the last versions from enlightenment.org (or checkout from Enlightenment git) and build both EFL and E from sources.
I'm on git versions (dated some months ago) on FreeBSD 11.2. It's stable, I'm using it every day ~12hrs by day without freezes. I tested everything on FreeBSD 12 too without problems.
I did not (yet) tested the last released version of EFL.
You can ask for help in maillist if you have problems with build.
How can I track down the problem?
Fri, Apr 12
Feb 28 2019
This isn't fixin anything.
Feb 27 2019
Nothing changed adding the header.
Please test the attached revision.
likely related to @bu5hm4n 's changes
Feb 26 2019
@netstar one for you?
Nov 4 2018
Oct 26 2018
Sep 22 2018
checking whether the C compiler works... no
@netstar could you have a look at this?
Apr 13 2018
Mar 12 2018
I need more info about meson. What file describes how should meson set paths?
I'll try to search myself, but it is really difficult for me, some months ago I even did not know that this build system exists...
Mar 11 2018
@Peter2121 Maybe you could take a look into that?
The last Git version of Enlightenment has no problem with sysactions if I force sysconfdir as mentioned, configuring meson build.
However, it seems strange for me that for FreeBSD build we need to force using /usr/local/etc as sysconfdir. I think that it should be detected automatically by meson somehow as /usr/local/etc is default configuration directory for all non-base software.
Okay that above commit was wrong.
fixed by above commit.
Mar 10 2018
ok i know how to fix this, need to speak with someone to make sure it's the right fix....trivial really,
Feb 28 2018
Oct 24 2017
Sep 29 2017
Sep 27 2017
perhaps clang is not respecting the gdb options... check clang's manual for debug options... maybe you have to not even use gdb... use lldb by hand. i don't know.
By default - CLANG
Sep 26 2017
ummmmm ok. well CFLAGS is set... using clang or gcc?
Yes, I compile as root
Sep 25 2017
you compile as root?
Voila my root environnement (set in profile):
ummmmm then it should have filenames and line numbers there too. unless you didnt have CFLAGS set when building efl (before configure runs)...
I install EFL an E normally - autogen/configure/gmake
Nothing could strip binaries. Could it be CLANG issue?
Sep 24 2017
this next issue... it's crashing deep inside the nvidia drivers. why - don't know. no symbols, data or info as to why...
those flags should do it... but it's missing the info... did something strip the binaries? did you compile and install by hand?
One more freeze, this time - with OpenGL rendering active.
What compile options should I use to have line numbers shown in the backtrace?
I used the ones from https://www.enlightenment.org/docs-efl-start :
export CFLAGS="-O2 -ffast-math -march=native -g -ggdb3"
well the freeze is in the sw rendering code path... so by switching engine you're avoiding that code path. i've never seen this on linux though. so my other comment about wanting at least a line number still stands. then i might know what is triggering it there. maybe a read-only bit of memory being written to somehow...
It seems that with OpenGL rendering the freeze is much more difficult (or impossible) to reproduce - the actions that always froze E before, don't freeze it now, I cannot reproduce it for the moment.
BTW, in the meantime I upgraded EFL and E to the last versions from Git - so maybe it helps too.
Anyway, as the problem was randomly present - I continue my tests, it's my everyday laptop, so if the problem is still here - it will be captured.
Probably, at one moment I reset the rendering to software from OpenGL I'm using normally.
I've just changed it to OpenGL (NVIDIA drivers), I'll try to reproduce the freeze.
Sep 23 2017
the fascinating thing is... you're using the software engine for e? well well... must not be too slow if you are not using acceleration. :)
I noticed that E freezes regularly when I am debugging something in Netbeans on my laptop.
I rebuilt EFL and E with more debug info, I'll try to upload some backtraces here.
Sep 13 2017
btw - i've been trying to update my freebsd vm to try... but network in my neck of the woods is failing to connect to pkg.freebsd.org ... something is up.
Aug 27 2017
...the CPU is 100%, used by Enlightenment process.
Jun 23 2017
May 25 2017
Pretty certain this was a side-effect of no efreetd. E now will not fail without efreetd, but we have efreetd working again on FreeBSD.