On Tue, Jan 8, 2013 at 11:24 PM, Arvind R <arvin...@gmail.com> wrote:
> On Wed, Jan 9, 2013 at 5:56 AM, Arvind R <arvin...@gmail.com> wrote: > > On Wed, Jan 9, 2013 at 5:28 AM, Gustavo Sverzut Barbieri > > <barbi...@profusion.mobi> wrote: > >> On Tue, Jan 8, 2013 at 8:26 PM, Gustavo Sverzut Barbieri < > >> barbi...@profusion.mobi> wrote: > >> > >>> On Tue, Jan 8, 2013 at 7:14 AM, Arvind R <arvin...@gmail.com> wrote: > >>> > >>>> On Tue, Jan 8, 2013 at 2:18 AM, Gustavo Sverzut Barbieri > >>>> <barbi...@profusion.mobi> wrote: > >>>> > On Mon, Jan 7, 2013 at 9:14 AM, Arvind R <arvin...@gmail.com> > wrote: > >>>> > > >>>> >> Hi all, > >>>> >> > >>>> >> After getting xine backend working in emotion, tried generic (vlc) > >>>> >> backend. Nope - doesn't work -:( > >>>> >> > >>>> >> Problem 1: Using the example source, now need to add: > >>>> >> emotion_object_module_option_set(em, "player", "vlc"); > >>>> >> > >>>> >> It does not fall-back to the default generic player. > >>>> >> > >>>> >> Problem 2: > >>>> >> em_player_vlc cannot be found, because generic_module_init() fails > to > >>>> >> set the prefixes proper. > >>>> >> > >>>> >> So put printf() and recompiled. (Is there is a small howto on the > eina > >>>> >> logging system?) Output: > >>>> >> > >>>> >> evas engine: <auto> > >>>> >> emotion backend: generic > >>>> >> vis: 0 > >>>> >> geometry: 0 0 960x540 > >>>> >> generic_module_init: initing libdir to /usr/lib/x86_64-linux-gnu > >>>> >> > >>>> > > >>>> > this seems wrong already, is it PACKAGE_LIB_DIR? why does it contain > >>>> > x86_64-linux-gnu? in Makefile.am it's just $(libdir), did you > specify > >>>> > something with --libdir? > >>>> > > >>>> Yes. '$prefix/lib/$DEB_ARCH. The x86_64-linux-gnu is correct. > >>>> > > >>>> > > >>>> >> generic_module_init: got libdir /usr/lib/lib > >>>> >> > >>>> > > >>>> > yet another very weird result. double "lib" in the path? Where are > you > >>>> > installing these things? > >>>> > > >>>> > eina_prefix_new() will use the given symbol (emotion_object_add) and > >>>> dladdr > >>>> > to know which file it came from. Should be the libemotion.so. Then > it > >>>> gets > >>>> > the directory where libemotion.so is contained, should be /usr/lib > if > >>>> it's > >>>> > /usr/lib/libemotion.so. Then it will remove the "lib" part to get > the > >>>> > prefix, later adding this again (this is what it should do, did not > >>>> test to > >>>> > see if it's correct). > >>>> > > >>>> Ah-ah! The logic is IMHO, wrong! My installation is a multiarch debian > >>>> install. The x86_64 libdir is '/usr/lib/x86_64-linux-gnu' and 32-bit > >>>> version in 'usr/lib32' on a x86_64-linux-gnu system and '/usr/lib/' on > >>>> a 'x86-linux-gnu' system. The modules get installed in sub-dirs of the > >>>> library, e.g. libemotion.so gets installed in > >>>> '/usr/lib/x86_64-linux-gnu/' and emotion modules in > >>>> '/usr/lib/x86_64-linux-gnu/emotion/'. > >>>> > >>> > >>> ok, got it and from this commit it seems to be handled > >>> http://trac.enlightenment.org/e/changeset/74709 > >>> > >>> (I mean the message, not the logic, will check that later). > >>> > >>> > >>> > >>>> This makes the 'MODULE_ARCH' variable in autoconf files unnecessary; > >>>> > >>> > >>> not really as it also includes efl version. Also will allow installing > to > >>> shared /usr, like NFS used by multiple platforms (ppc, x86...)... in > >>> theory, because in practice half of EFL doesn't conform with that > (emotion, > >>> ecore_imf, eeze/sensors, evas cserve2 binaries, efreet binaries...). I > plan > >>> to fix those soon. > >>> > >>> > >>> > >>>> and, as I have on my system (untested -:(), a lib32 AND a x86_64 > >>>> installation possible. This will conform to most packaging systems > >>>> AFAIK, and definitely to Debian. > >>>> If the logic is modified to scan from right to left the absence of > >>>> '^lib' substring to get the prefix, and later add ALL the subsequent > >>>> parts, all will be fine. Better still, have eina_prefix_new take the > >>>> $PREFIX value too to enable a left-to-right scan. > >>>> > >>> > >>> > >>> I'll check the logic, but it's worth for you to check if you have that > >>> patch in your version. > >>> > >> > >> the logic assumes a magic file to check. That's why most libraries > started > >> to ship with "checkme" files. > > > > checkme files for eeze|efreet|ecore-imf|evas installed in /usr/share/ > >> > >> I did a fix for single tree efl as r82429. It would be nice if someone > >> could backport this to stable branch. > > > > Will check with current tip. > >> > -:( Now have to set link from /usr/lib/emotion to > /usr/lib/x86_64-linux-gnu/emotion > Problem IMHO not fixed. > Hi, Would you let me know the configure line you pass? (You can get that from config.log file) What is strange right now is that if you're getting divergence as you said, likely the libraries are being compile with one --libdir= but the resulting binaries are being placed elsewhere. One case would be to compile with --libdir=/usr/lib (default) but the libraries are being (manually? dpkg?) copied to /usr/lib/$(ARCH). In that case the proper way would be to compile with --libdir=/usr/lib/$(ARCH). I want to be able to reproduce the problem here so I can investigate and understand it better. My current fix is not that good, as now it will search too much :-/ -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -------------------------------------- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 ------------------------------------------------------------------------------ Master Java SE, Java EE, Eclipse, Spring, Hibernate, JavaScript, jQuery and much more. Keep your Java skills current with LearnJavaNow - 200+ hours of step-by-step video tutorials by Java experts. SALE $49.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122612 _______________________________________________ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users
