From: Carsten H. (T. R. <ra...@ra...> - 2006-10-28 01:34:17
|
On Sat, 28 Oct 2006 01:35:39 +0200 Christian Wiese <mo...@op...> 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) ra...@ra... 裸好多 Tokyo, Japan (東京 日本) |