now looks good

this doesn't seem to delete decl.eo, remove that from tree too

AM_CONDITIONAL inside EFL_LIB_START_OPTIONAL would result in the
variables not being defined with Elua disabled.

fair enough.

maybe using clang and ld.lld would also be worth a try (lld should be even much faster than gold, and clang should also be at least a little bit faster)

As talked over previously, I will claim this task and integrate C# into the current documentation generator. Before that, I intend to rewrite the documentation generator using a simpler design, so that it will become easier to integrate C# and other languages into it.

That doesn't make it okay.

This will obviously cause issues when e.g. using an efl dll on Windows with visual studio toolchain

keep in mind that this is not portable, it's a GNU extension, so not sure if it's a good idea to use it in a public header

@simotek think you could get me the backtrace so that i can finally deal with this?

I think this is currently not easily solvable using autotools. Perhaps setting LD_LIBRARY_PATH at the points when executables are being run would do the thing, but I'd say this is something to be addressed with switching to Meson.

well, i tried looking into this but as things are right now it's unsolvable. I guess we'll need to decide 1) whether this needs a solution, considering all the eo files have new non-doxygen docs 2) what would be the best approach to making it solvable...

this will need feature work so i removed the tag, but it'll get done for 1.22

the promise/future code has been substantially reworked, so it's unlikely this same bug would appear

this code is not present in recent EFL anymore, so it's unlikely the same crash would be present

this is safe to close at this point