testing a bit more, this script is very effective for stopping e for up to 5 seconds for me. First send a via notify-send which returns immediately, start date and then shellementary. Needs a bit higher load and a hardware accelerated video playing. Browsers like Firefox and Chromium are helpful as well. Restarts after 900 seconds which seems enough to purge the kernel cache of shellementary and its librarys.

For me I've found a relatively reliable testcase for this: shellementary. When I play a video, have a browser open and a system load roughly equal to the number of cpu cores, e hangs for up to 5 seconds when opening it the first time. So it seems either e or Xorg is waiting for the creation of this window, but shellementary sometimes takes too long (maybe on memory init?)

Do you have something like valgrind? The future seems to be completely empty other than the next and promise which is weird.

I could catch the same crash:

Fixed in Meson, tested OK. Hope the new version of Meson will be released soon.

Probably fixed in Meson's master: https://github.com/mesonbuild/meson/pull/4410
I need some time to test it...

This pretty much sounds like it's a freebsd thing to fix in the ports or in their install of meson. there is no choice on the install location for pc files in our build files at all... it's wherever meson thinks they should go. That is 100% the right thing to do.

OK, I've got it.
There is a hack in the ports system, it redirects *.pc from lib to libdata during stage (and install).
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218067
So, probably, we only need to put some info into the docs about the behavior change from autotools to meson.

In T8360#146698, @lauromoura wrote:

I'm not a FreeBSD user but how does other meson-based projects deal with pkg-config? Through USES = meson when porting?

Isn't it a case of patching Free BSD's own Uses/meson.mk to point to the correct directory? (The best reference I could find for it was this patch adding it https://reviews.freebsd.org/D10409)

In T8360#146641, @Peter2121 wrote:

Right now, after install, EFL libs are not available for building software under FreeBSD. Even Enlightenment does not build. I think it is very bad. Asking a user who wants to build Enlightenment to add a custom path for pkg config is a bad idea. It is a regression passing to meson build from autotools. If it can be solved on EFL level - IMHO it should be solved. If you consider that it should be fixed on meson level - try to ask it to meson devs.
Anyway, it must be patched in FreeBSD port, if not - EFL 1.23 will not be accepted in ports tree. The standard path for *.pc files in FreeBSD - /usr/local/libdata/pkgconfig

In T8360#146695, @netstar wrote:

Hi Peter no issue with Efl on freebsd or openbsd here. I think the pc issue is best fixed by the packager or port maintainer. You could help them with that????

Hi Peter no issue with Efl on freebsd or openbsd here. I think the pc issue is best fixed by the packager or port maintainer. You could help them with that????

Right now, after install, EFL libs are not available for building software under FreeBSD. Even Enlightenment does not build. I think it is very bad. Asking a user who wants to build Enlightenment to add a custom path for pkg config is a bad idea. It is a regression passing to meson build from autotools. If it can be solved on EFL level - IMHO it should be solved. If you consider that it should be fixed on meson level - try to ask it to meson devs.
Anyway, it must be patched in FreeBSD port, if not - EFL 1.23 will not be accepted in ports tree. The standard path for *.pc files in FreeBSD - /usr/local/libdata/pkgconfig

I do not really want to emulate install behaviour from autotools in our meson build. The platform that should fix this is meson itself, in the pkgconfig module itself. I do not want to fix this in efl, enlightenment, etc. etc. Would it be a burdon to keep this behaviour for now and bring this bug to the attention of the meson project ?

In T8360#146629, @bu5hm4n wrote:

This was always the case, also in autotools. And is also the case for linux. Our installation and build guide also states that you should use PKG_CONFIG_PATH=/usr/local/lib/pkgconfig.

This was always the case, also in autotools. And is also the case for linux. Our installation and build guide also states that you should use PKG_CONFIG_PATH=/usr/local/lib/pkgconfig.

install_dir option

LGTM, thanks.

makes sense.

In T7486#145197, @c wrote:

Bug report, analysis, and fix are almost a year old ???

Bug report, analysis, and fix are almost a year old ???

this should be something for @barbieri and @ManMower, but they haven't been active since the beginning of the year.

Sorry no update, both of those patches are were already applied in 0.22.4.
Thanks for the doc links.

raster fixed an SEGV on close in 0.22.4 with rE638ffe58538478ede9f9000db370ec5e853635e8 and i had a SEGV which was closed with rEbf146faf7289035eade9875735869de4da7622d4.

EFL 1.20.7
Enlightenment 0.22.4

one constant error that shows up at the console tells to: eina_btlog << EOF EOF.
sometimes it tells the resource is null os nonexistent. dont have it right now. maybe will try to catch and upload here so you have more detailed information..

Me too, sometimes I have problems with window switcher. It does not show the list, but only the next window icon & name. But I don't need to restart the session, the next invoking the switcher is normally correct.
And UI does not hang for me with the last versions of E/EFL.

In T7803#139702, @cederom wrote:

not really :-( some issues that i have noticed:

1. ui hangs but mouse moves. sometimes after several minutes things get back to normal sometimes not.
2. window switcher / selector is buggy. almost always with virtualbos running it cannot switch back to other windows and does not show windows on the list while switching with Ctrl+Tab. this is critical as i have to restart session and interrupt my work.
   
   that never happens on the same machines running xfce4 or lxqt..

not really :-( some issues that i have noticed:

1. ui hangs but mouse moves. sometimes after several minutes things get back to normal sometimes not.
2. window switcher / selector is buggy. almost always with virtualbos running it cannot switch back to other windows and does not show windows on the list while switching with Ctrl+Tab. this is critical as i have to restart session and interrupt my work.

In T7803#134209, @cederom wrote:

Thank you Peter! Enlightenment really rox! Just as my beloved FreeBSD!

I don't see the segmentation fault closing emixer on my laptop.
FreeBSD 11.2-RELEASE-p9 Enlightenment 0.23.0.alpha EFL 1.22.2

Could you please provide the Enlightenment and Efl version you are using? devd, pulseaudio and dbus version would probably also help.

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?

This isn't fixin anything.

Nothing changed adding the header.

Please test the attached revision.