[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 <morfoh@opensde.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
dfb libs.:

libecore_directfb_la_LIBADD = \
$(top_builddir)/src/lib/ecore/libecore.la \
@DIRECTFB_LIBS@

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
the chain).:

libecore_evas_la_DEPENDENCIES = \
$(ECORE_X_LIB) \
$(ECORE_FB_LIB) \
$(ECORE_DIRECTFB_LIB) \
$(top_builddir)/src/lib/ecore/libecore.la

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:

if BUILD_ECORE_EVAS
ECORE_EVAS_LIB = $(top_builddir)/src/lib/ecore_evas/libecore_evas.la
else
ECORE_EVAS_LIB =
endif
...
ecore_test_LDADD = \
$(top_builddir)/src/lib/ecore/libecore.la \
$(ECORE_X_LIB) \
$(ECORE_TXT_LIB) \
$(ECORE_JOB_LIB) \
$(ECORE_FB_LIB) \
$(ECORE_EVAS_LIB) \
$(ECORE_CON_LIB) \
$(ECORE_IPC_LIB) \
-lm @iconv_libs@

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

> Cheers,
> --Chris
> 


-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler)    raster@rasterman.com
裸好多
Tokyo, Japan (東京 日本)