[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [E-devel] ecore directfb problem + patch
On Sat, 28 Oct 2006 01:35:39 +0200 Christian Wiese <firstname.lastname@example.org> babbled:
> Hi folks,
> first of all I want to take the oportunity to say thank you for the
> great evolution dr17 had within the last month!
> I'm very happy after updating to the cvs snapshot of 2006-10-22 :)
> Neverthenless I ran into directfb related problems while while trying
> to build ecore.
> Linking of ecore_test and ecore_evas_test failed.
> It seems to me that there ECORE_DIRECTFB_LIB and DIRECTFB_LIBS are
> missing within the Makefile.
> Attached is the log of the failed ecore build and a patch that fixed
> that seems to fix the problem.
> Any comments about the problem and the patch are highly welcome!
the patch seems to indicate libtool is not building library linking
dependencies in. what should happen is:
1. you enable ecore_directfb explicitly for build (not that it will be useful
to you unless you are doing specific app development for specific devices etc.
etc. - so unless you have a particular NEED for dfb support - don't enable it.
it's not enabled by default - same goes for evas).
2. when ecore builds it will build ecore_directfb and LINK ecore_directfb TO
libecore_directfb_la_LIBADD = \
3. ecore_evas will build - it will detect dfb support for evas AND also
ecore_directfb - it will link to evas AND ecore_directfb (thus ecore_directfb
sucks in any lib deps into ecore_evas for dfb VIA ecore_directfb - just follow
libecore_evas_la_DEPENDENCIES = \
4. the ONLY directfb code in evas's test code (in src/bin) is an ecore_evas
call to test dfb canvas wrapping. thus ecore_evas is already linked to:
ECORE_EVAS_LIB = $(top_builddir)/src/lib/ecore_evas/libecore_evas.la
ecore_test_LDADD = \
so thus - dfb linking should be sucked in VIA ecore_evas that then sucks in
from ecore_directfb and ultimately sucks in dfb lib links.
this works for everything else. ecore_x for example, ecore_txt (with -liconv)
etc. etc. - they suck in their dependencies and so on down the chain.
now - your patch just ignores the dependency tree and bypasses it linking
directly. this isn't a fix - it's a hack workaround. something is causing
libtool on your system to not follow the dependency tree for linking.
1. have u tried the tarball snaps on enlightenment.freedesktop.org ? they are
pre-built. you dont need (nor should you) run autogen.sh - they are built using
autofoo (autoconf/automake/libtool) here on my system(s) and the resulting
tarballs do obey dependency trees. if these work for you (just ./configure
--my-options && make ... etc.) then its your local libtool dev installation
that somehow it broken. i suggest you dig in that direction then (change
distribution to one that ships non-broken libtool packages, or fix the
packages, or get maintainers of the packages to fix them for you)
2. if the problem persists - libtool somehow by its logic is deciding that
somehow it can't follow 2 levels of dependencies (totally weird) and something
is stopping it - find out what that is.
because... "works for me here (tm)".
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler) email@example.com
Tokyo, Japan (東京 日本)