OK, with if sys_linux == true it works better ;)
I could build EFL, Enlightenment and Terminology, everything works fine on FreeBSD 12.

So, I took my test PC (FreeBSD 12) , I've uninstaled all EFL stuff, I've cloned EFL repo and I've patched src/lib/ecore_file/meson.build like in Diff 19894.
Then I've declared the following environment variables:

bu5hm4n,
Libinotify is present in FreeBSD as port:
FreshPorts
You can see the limitations of this library in pkg-message section of this page. This library is used for 50+ ports and they manage to use it correctly. I referenced two projects that added support of FreeBSD's inotify without hacks: polybar, gerbera It does not seem to me that they needed to work hard to add this support ;) Anyway, if EFL cannot use it correctly under FreeBSD - we need a meson option to disable it without removing headers.

Make sure you remove any package that is including inotify headers because the EFL build will see these headers and assume we can use inotify but we cannot use it on FreeBSD. If you have inotify.h in /usr/local/include or elsewhere, remove it, or the package that is pulling in this bogus header.

Sorry, netstar, the problem explained in this post is still present, building with your options.
Errors about inotify_* changed to warnings (will it run correctly after build?)

...and a commit to add FreeBSD libinotify support to gerbera:
https://github.com/gerbera/gerbera/commit/3cec05f3b615b768f4dc0caff7defa549b489e23

There is a thread in FreeBSD forum about porting polybar, they had libinotify problems too...
https://forums.freebsd.org/threads/polybar-i-want-to-give-it-a-try.62494/

If I remove libinotify I get another error:

FAILED: src/bin/efreet/efreet_desktop_cache_create
cc  -o src/bin/efreet/efreet_desktop_cache_create 'src/bin/efreet/d57513e@@efreet_desktop_cache_create@exe/efreet_desktop_cache_create.c.o' -Wl,--as-nee
ed -Wl,-O1 -O2 -ffast-math -march=native -g -ggdb3 -Wl,--start-group src/lib/efreet/libefreet.so.1.22.0 src/lib/eina/libeina.so.1.22.0 src/lib/eo/libeo.
o.1.22.0 src/lib/efl/libefl.so.1.22.0 src/lib/ecore/libecore.so.1.22.0 src/lib/eet/libeet.so.1.22.0 src/lib/emile/libemile.so.1.22.0 src/lib/ecore_file/
ibecore_file.so.1.22.0 -ldl /usr/local/lib/libunwind-generic.so /usr/local/lib/libunwind.so -ldl -ldl -ldl -ldl -ldl -ldl -ldl -ldl -ldl -ldl -Wl,--end-
roup -pthread '-Wl,-rpath,$ORIGIN/../../lib/efreet:$ORIGIN/../../lib/eina:$ORIGIN/../../lib/eo:$ORIGIN/../../lib/efl:$ORIGIN/../../lib/eet:$ORIGIN/../..
lib/emile:$ORIGIN/../../static_libs/lz4:$ORIGIN/../../lib/ecore:$ORIGIN/../../static_libs/buildsystem:$ORIGIN/../../lib/ecore_con:$ORIGIN/../../lib/eldb
s:$ORIGIN/../../static_libs/http-parser:$ORIGIN/../../lib/ecore_file:$ORIGIN/../../lib/ecore_ipc' -Wl,-rpath-link,/usr/home/peter/Programming/Prog-EFL/t
st-efl/efl/build/src/lib/efreet:/usr/home/peter/Programming/Prog-EFL/test-efl/efl/build/src/lib/eina:/usr/home/peter/Programming/Prog-EFL/test-efl/efl/b
ild/src/lib/eo:/usr/home/peter/Programming/Prog-EFL/test-efl/efl/build/src/lib/efl:/usr/home/peter/Programming/Prog-EFL/test-efl/efl/build/src/lib/eet:/
sr/home/peter/Programming/Prog-EFL/test-efl/efl/build/src/lib/emile:/usr/home/peter/Programming/Prog-EFL/test-efl/efl/build/src/static_libs/lz4:/usr/hom
/peter/Programming/Prog-EFL/test-efl/efl/build/src/lib/ecore:/usr/home/peter/Programming/Prog-EFL/test-efl/efl/build/src/static_libs/buildsystem:/usr/ho
e/peter/Programming/Prog-EFL/test-efl/efl/build/src/lib/ecore_con:/usr/home/peter/Programming/Prog-EFL/test-efl/efl/build/src/lib/eldbus:/usr/home/peter
Programming/Prog-EFL/test-efl/efl/build/src/static_libs/http-parser:/usr/home/peter/Programming/Prog-EFL/test-efl/efl/build/src/lib/ecore_file:/usr/home
peter/Programming/Prog-EFL/test-efl/efl/build/src/lib/ecore_ipc
src/lib/ecore_file/libecore_file.so.1.22.0: undefined reference to `inotify_add_watch'
src/lib/ecore_file/libecore_file.so.1.22.0: undefined reference to `inotify_init'
src/lib/ecore_file/libecore_file.so.1.22.0: undefined reference to `inotify_rm_watch'
cc: error: linker command failed with exit code 1 (use -v to see invocation)

Do you have libinotify installed?
config command was:

meson setup --wipe build -Decore-imf-loaders-disabler=xim,scim,ibus -Db_lundef=false \
-Dxinput22=true -Dbuffer=false -Dfb=false -Ddrm=false \
-Dtslib=false -Dharfbuzz=true -Dwl=false -Dnetwork-backend=connman \
-Devas-loaders-disabler= -Dbindings=cxx,luajit -Dbuild-examples=false \
-Dsystemd=false -Deeze=false

I used the following command to configure the build:

Sorry, the workaround does not work.
I deleted build directory and reconfigured meson with the proposed option.
The build still fails.

vtorri, I don't think it's related as in the bug they discuss a runtime problem, but we have a build time problem. I've just declared the variable as 'extern' and the build passed, E works correctly with the compiled version of EFL (I'm using it since 2 days). BUT, I don't know if somewhere this function was used, so MAYBE we are concerned by 220103 bug too.

Nothing changed adding the header.

Nothing changed adding the unistd.h header.
Anyway, there is no

environ

variable declared in system's unistd.h.
I cannot find any header with such declaration.

I confirm that this commit solved the problem.
Thanks a lot, raster!

I mentioned one interesting thing more.
When I switch to another task, in case of a lost mouse click - not only keyboard works correctly in the active window, but mouse scroll works correctly too. Only mouse clicks (left and right buttons, additional buttons too) are lost for the first click. So, for example, if I switch to another window using mouse and WinList - I cannot use WinList again immediately, the first click of additional button is lost, WinList does not get active.

raster,
Sure, the click to dismiss winlist must be lost, I don't count it. I perfectly understand that it is used like 'escape' key. I mean the next click is lost.

I've just used 'git clone' command to clone the repository.
I think I'm on 'master' as I see your last modif in src/modules/winlist/e_mod_main.c:
static Eina_Bool _e_mod_action_winlist_wheel_cb(...

Sorry, raster, the problem is still present with the GIT version with your modifs.
Only the first time switching windows with mouse and WinList the focus is not lost. Then it is always lost till I use once Alt-Tab. Then it is not lost once etc.

For me it is neither related to the system charge nor to CPU use by Enlightenment.
It seems to be a bug in WinList module as it cannot be produced by keyboard manipulations, only by mouse.

Some additional tests with EFL 1.21.1, Enlightenment 0.22.4 on FreeBSD 12BETA2.
The problem is still present.
Really interesting point is that the problem is not present on FIRST task switch. If I open some windows and then use WinList with mouse only - everything works as expected. If I then retry - the focus is lost as explained. And if then I use WinList with keyboard (Alt-Tab) - the next time I use it with mouse it works OK - once.

It seems that the problem is NOT present in GIT version.
It would be nice to see a new release with the fix ;)

I've just tested it a little bit more.
The problem is really simple to reproduce if I click inside winlist, choosing a window to activate. The area of winlist where I click does not matter, this click just closes winlist.
So:

1. Additional mouse button to activate winlist
2. Mouse wheel to choose window
3. Mouse left-click inside winlist
4. Selected window becomes active (decoration), but the first click inside the window does not work (no focus), only the second one.

@netstar, you closed it the 1 Mars ;)
...and yes, I found how to FORCE_SYNC_RENDER, you mentioned it later here (I did not see).
Were your E fixes included in 0.22.2? What will be the version of EFL with your fixes? I want to ping enlightenment@freebsd.org to update the ports, but it would be better to wait the both products updated.

Finally, I could test the last E build with the last EFL on my test laptop with FreeBSD 12 and HDD.
The stability is greatly improved, I could not freeze it. So I think that the problem is solved.
Note that I did NOT set _FORCE_SYNC_RENDER (I still don't understand how to do it).

The previous versions of EFL were removed with

ninja -C build uninstall

Digging into /usr/local/lib, I found some EFL-related dirs without files inside. I removed all these dirs. Then I cloned again EFL repository and I could build it. I'll test again after some commits in EFL tree, pulling the modifications.

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...

@felipealmeida, what log do you want to see?
I still have the error I mentioned in the first post here, only the filename changes. These files (*.hh) do not exist in source tree (that's why compiler segfaults).
It seems that the build system mixed *.h and *.hh files somehow...

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.

Sorry, still does not build with

lib/ecore/efl_io_buffered_stream.eo.hh

lost.

The file lib/evas/canvas/efl_canvas_surface_x11.eo.hh is not present in my src.
In the old directory lib/efl/interfaces/efl_gfx_gradient_linear.eo.hh is not present, in the new one it is present.
Some strange things are happening during the build...

Strange...
I cloned again the repository (the first try was 'git pull' to the existing dir) and the error has changed:

I don't see in your commit the patch for src/bin/e_object.c, is it forgotten?

The old gadget is correctly showing the current frequency with digits, so I can see that it changes (powerd is active).
The new one now works exactly as the old one - the pointer is moving in opposite direction: by default (max frequency) it's on minimum, when the frequency decreases - it turns right to reach the right position when the frequency is minimal. For me the minimum is 800MHz, the maximum is 2600MHz (I can see it on the old gadget).
BTW, visually it is not really cool - on the min and max positions the pointer is not really visible.
...And the digits on the old gadget was not so bad idea ;)

The problem is still present in last Enlightenment (GIT) built with last EFL (GIT).
The most simple way to reproduce - add mouse bindings like I described, then start two windows on the same screen (Firefox and Thunderbird), then from Firefox activate 'Windows List' with mouse button - Thunderbird is selected and put in front), then click-left somewhere inside Thunderbird. 'Windows List' will close, Thunderbird will get focus. Click somewhere inside Thunderbird window (for example, to change the active folder) - nothing happens. The second click in the same place will work correctly.

EFL & E from GIT on FreeBSD 11.1.
New CPUClock gadget still does not work correctly, the old one neither :(

I've pulled EFL and Enlightenment from GIT, applied your patch and installed.
Then I tried to install a new app and access the main menu immediately after install. I always had a freeze on this operation, I have no such freeze today. So it seems to go better.
Tomorrow I'll try to test on another laptop with FreeBSD 12.0 installed.

Is there any possible workaround in the current state?
Could you prepare a small tool to put in evidence the popen problem? So I can try to open a ticket in FreeBSD tracker...
Maybe there are some side effects - using popen in unusual way? I doubt that nobody found this FreeBSD problem before...

It seems that it is!!
I deleted all themes with svg files and deleted 'scalable' dir from 'hicolor', so there is no svg files in /usr/local/shared. Then I killed efreetd, deleted efreetd cache and efreetd socket and restarted the laptop. After reboot I cannot reproduce the problem of main menu freezes, new apps installed OK and new icons are shown in the menu.

I've just tested it with EFL from git of 30/01/18 23:28 - still crashes.
It's on FreeBSD 12-CURRENT (PCBSD flavor).

Sorry, still crashes for me (T6647)

I've just tested on 12-CURRENT with EFL and E from git - the problem is still here, simple to reproduce.

Yes, I can interact with other windows, but no window has focus.

Just to precise that sometimes the focus is lost after closing a window too. Another window becomes active, but does not get a focus.

Enlightenment never starts under Valgrind on FreeBSD, I cannot produce the logs.

Should I re-post the Valgrind log to other ticket? Is it really useful?

Well, I tried to start E with Valgrind.
Under Xephyr it does not work at all (probably the problem of support of OpenGL under Xephyr).
So, I modified enlightenment.desktop to start it from lightdm. And it does not initialize correctly. I was waiting for 30 mins, then I killed the process. It was restarted automatically, but again - it did not finish the initialization. Maybe, I do something incorrectly.
The log file is attached.

Sorry, another try to freeze it was "successful":

Let me know if you need any debugs on FreeBSD 11.0.

I cannot reproduce the freeze on git version of E, compiled with "-g -ggdb3 -O0" CFLAGS.
netstar, what about you?

netstar, do you mean I should try git version of E?

[Desktop Entry]
Encoding=UTF-8
Version=0.9.12
Type=Application
Name=Lucidor
Icon=/home/peter/Icons/lucidor.png
TryExec=/bin/sh /home/peter/bin/lucidor-0.9.12/lucidor.sh
Exec=/bin/sh /home/peter/bin/lucidor-0.9.12/lucidor.sh
Categories=Viewer;Office;

Xephyr is not installed on my system, Valgrind neither. I'll try to debug it tonight, having more time.

Could fvwm be replaced by LXDE? I have E and LXDE installed already, fvwm must be added...

netstar, I'm on FreeBSD 11.0-RELEASE-p8. I use lightdm to start E. Valgrind is not installed, but I can try to add it and debug E with it. But I need the detailed instructions (used it once, some years ago on RPi to debug a small app...) I have no idea - how to correctly start E under Valgrind.

so i doubt it's that.

Raster, how can you explain that I was working 10 hours on the PC, using the menu many times, than I added (manually) a desktop file and the next time the menu freezes my PC?

Nvidia, the driver is nvidia-driver-340-340.102.

I just tried to open the menu, nothing more. At the moment of the crash, E was opening the right part of the menu, this part stays semi-transparent on crash, never completely painted.

I think to reproduce this problem for sure when I add a *.desktop file in /usr/local/share/applications
Then, if I try to open the main menu - my E always freezes. Always. As the method of tracking the changes in the directory is different on *BSD - it could explain why the problem is not present in Linux.

I did not see any relation with minimizing/restoring windows.

On the Cpufreq gadget (in a shelf) the arrow does not move at all (stays on minimum) but the digits show the actual frequency.
On the CPUClock gadget (in a bryce) arrow moves in the opposite direction.

One more freeze, slightly different

I've got two nice freezes on E22 beta. The both are related to "old" gadgets - ibar and main menu. There are more debug info here, hope it helps to find the source of problems.

By default - CLANG

Yes, I compile as root

Voila my root environnement (set in profile):

I install EFL an E normally - autogen/configure/gmake
Nothing could strip binaries. Could it be CLANG issue?

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"

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.

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.

...the CPU is 100%, used by Enlightenment process.