Ecomorph issue to include it in newer versions

Hi hackers & developers :slight_smile:

I'm working on the next Elive versions (amd64, debian buster, etc...) and I'm having a small issue trying to make it working back Ecomorph (special effects / compiz), which seems to be related to the compiling flags / compilation specific things (autotools, CFLAGS, etc)

Before I had to remove the --as-needed option in LDFLAG to fix a similar issue, but now I still seeing this one:

ecomorph: symbol lookup error: /usr/li/i386-linux-gnu/ecomp/libanimation.so: undefined symbol: animGetF

How to reproduce:

  1. Download an '3.7.xx' Elive build (sorry, they are not available to download yet, I still working on making them more ready to use, but if you have a recent debian/ubuntu system, Installed or Live you should be able to reproduce the problem from it too, no E desktops* are needed for it)
  2. remove already installed (ecomorph) libecomp* packages:

apr --purge libecomp*

  1. get the source code of the ecomorph: GitHub - Elive/ecomp: compositing manager for e17 based on compiz
  2. install dependencies:

api pkg-config xsltproc libxslt1-dev libxrandr-dev libxinerama-dev libxdamage-dev libxcomposite-dev libpango1.0-dev libjpeg-dev libice-dev libglu1-mesa-dev ccache intltool

  1. configure and install in your system:

export LDFLAGS="-Wl,--no-as-needed -ldl"
eval $( dpkg-architecture )
./configure --enable-inotify --prefix=/usr --libdir="/usr/lib/$DEB_BUILD_MULTIARCH" && make && sudo make install && echo COMPILATION DONE

  1. make sure that you don't have a compositor running on your desktop
  2. run it:

ecomorph ini inotify

  1. trigger the problem: now by simply opening and closing any window it should trigger the error shown before

Notes:

  • this error can be reproducible in E16 too, which can be easier to do it from it to avoid E17 relations to ecomorph
  • no need to use the emodule-ecomorph, just this ecomorph executable
  • the problem is not related to e17, its only in ecomorph and its probably related to new versions of gcc (they way it compiles), probably it just needs to be compiled with different flags or update the autotools files to a better management

Related: Redirecting…


Updates:

  • it is possible that we won't use anymore ecomorph / composite, so looks like moving to E22+ is the way, too many work is needed for E17 that could be done in E22 instead, and moving to an updated Enlightenment. Yeah, this means bye bye ecomorph :thinking:

Any volunteer to try make it working ? comment here! :furrydance: :happy_dance::1up::typing::love:

Mentions: @PrinceAMD, @triantares

Isn't there something discrepant in ecomorph looking for i386 libraries on a 64bit version?
Or is that intentional?

Nothing related :slight_smile: the test was made while I was testing a i386 system (specially to have a bigger compatibility in some tests) but the issue is on both

I'm drawing a complete blank here. Besides setting off "--as-needed".
I saw a post somewhere advising to use LDLIBS in place of LDFLAGS but I don't have a machine at hand to test that. Maybe tomorrow......but it'll probably get messy.:neutral_face:

I did more tests today, reading things in google and: Better understanding Linux secondary dependencies solving with examples

The issue should be really related to how it is compiled, and linking the object/binary files etc... some expert in Autotools / Makefiles should be able to know what is going on :confused:

updated description ^

Well compiz does offer some of the effects ecomorph has but definitely not all...So quite a decision.
But then a few minor regressions to escape being boxed in by E17 might be for the best in the long run.

E22 simply cannot use compiz, ecomorph, compositor, or any other similar one, because Enlightenment integrated the compositor layer in the desktop, in other words: in e17 there's a composite layer too, but being an emodule you can disable it (and then you can use ecomorph), new Enlightenment versions cannot disable the compositor since is part of its core now

:nod: