On Wed, Jan 9, 2013 at 10:28 PM, Gustavo Sverzut Barbieri <barbi...@profusion.mobi> wrote: > 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) > ./configure --build=x86_64-linux-gnu --prefix=/usr --includedir=${prefix}/include --mandir=${prefix}/share/man --infodir=${prefix}/share/info --sysconfdir=/etc --localstatedir=/var --libdir=${prefix}/lib/x86_64-linux-gnu --libexecdir=${prefix}/lib/x86_64-linux-gnu --disable-maintainer-mode --disable-dependency-tracking --disable-rpath --enable-static --enable-doc
> 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 never compile manually. Using dpkg-buildpackage with debian/compat of 9. I use a python script to update my local svn/git/hg, create a build-directory, and build .deb packages. Could mail it if you want. I do modify (using quilt, and patces in debian/patches) the configure files to 1. read the micro-vesion from a file (.svnrev) in top-srcdir. 2. replace MODULE_ARCH in configure.ac with "." and remove them from Makefile.ams. Need to set to "." in configure.ac because some code uses the MODULE_ARCH definition All the files are installed in correct places and because efl/ethumb/emotion/elementary/terminology/e17/engage are all built using the same script. Works well for E17, X, and my bleeding-edge multi-media packages. > 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 :-/ Attaching my build script - DabE17. Hope you find it useful. Arvind Arvind
------------------------------------------------------------------------------ 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
