On Sun, 18 Apr 2010 02:24:48 +0200 mobi phil <[email protected]> said:
> Thanks for explaining.. but ... read on... (will answer to your prev email > as well) > > On Sun, Apr 18, 2010 at 1:40 AM, Carsten Haitzler <[email protected]>wrote: > > > On Sat, 17 Apr 2010 19:18:13 +0200 (CEST) Vincent Torri < > > [email protected]> > > said: > > > > > > Thanks, > > > > > > > > 1. the --enable/disable-ecore-*** flags are not documented in configure > > > > --help options for ecore > > > > > > they are: > > > > > > --enable-ecore-x enable the ecore_x module > > > > > > --enable-ecore-evas-software-x11 > > > enable Software X11 support in the ecore_evas > > > module. > > > > indeed they are. not sure what makes phil think otherwise. > > > > well tried again on: ecore-0.9.9.063, and I get > > > --enable-ecore-x-xcb > --enable-ecore-evas-software-x11 > > blah-blah > > but not --enable-ecore-x..... --enable-ecore-x-xcb enable the ecore_x module with XCB backend. [default=disabled] ... --enable-ecore-x enable the ecore_x module ... --enable-ecore-evas-software-x11 enable Software X11 support in the ecore_evas module. etc. all documents. current svn. > > > 2. I presume -software-*** options mean software rendering on the given > > > > backend. I do not understand the mixture in naming options like > > > > --enable-ecore-evas-directfb but --enable-ecore-evas-software-sdl > > > > > > 'software' means it uses no hardware acceleration > > > > > > --enable-ecore-evas-directfb enables (i think) an hardware accelerated > > > engine. Accelerated by directfb > > > > fine, but > --enable-ecore-evas-fb > > there is so far no accelerated one for fb, so .... ok... for me there is a > mixup.. /dev/fb is by its nature unaccelerated. it is a dumb framebuffer. there is no "other" rendering path. in evas its the fb engine. thus ecore-evas-fb > > the names are the names from the evas engine naming - and those names are > > used > > to differentiate - example. software-x11 vs xrender-x11 vs gl-x11 (all > > target > > 1xx - they use completely different methods of rendering though). chances > > are > > if you are fiddling with these compile options and dont know what you are > > doing > > - then you probably have no business fiddling with them. they are pretty > > simple > > and documented. > > > > well, once understanding them is ok... however I am sure this will further > confuse newcommers... newcomers swizzling compile options is a recipe for breakage and pain. - as i said... these are options for advanced use - not fresh-off-the-boat arrivals. if you barely understand efl and how it all works - you don't know what it is you are actually controlling. you need to udnderstand that first before you go control it. > > > > 3. With --disable-ecore-x it worked now, however at the end of building > > > > elementary I have the same error as during prev. builds: > > > > > > > > Unable to write image part "sky.jpg" as "images/2" part entry to > > > > ../../data/objects/test.edj > > > chances are you somehow had the jpeg loader for evas not build - it cant > > write > > that part because it can't load it. beats me why you dont have a jeg loader > > in > > evas. it's one of the most basic/core ones. maybe missing headers? or an > > undetectable version of libjpeg? in an odd place? > > it is not about /loading, but writing? (read the error message). actually i was wrong - no - it's the write failing: else if (mode == 2) bytes = eet_data_image_write(ef, buf, im_data, im_w, im_h, im_alpha, 0, qual, 1); if (bytes <= 0) error_and_abort(ef, "Unable to write image part " "\"%s\" as \"%s\" part entry to " "%s\n", img->entry, buf, file_out); (LOSSY is mode 2). > the same built on another machine indeed with libjpeg in standard place (I > do a sort of gentoo prefix build for test "products") > anyway this is not an issue. ldd shows correct dependency resolution... if a dependency isnt found for eet - edje_cc wont even begin to run. if its lazy linking and symbols are missing part way through - app will abort (crash/exit) with symbol missing error. i don;t know what's up with your environment - but eet has zero to do with x11 - it's much lower down. there is no good reason for it to fail here, unless you run out of ram... (as eet writes ans prepares the entire file in ram first before writing it out). > > > > However I have the libjpeg and other dependencies built. > > > > > > > > ->ldd `whence edje_cc` > > > > linux-gate.so.1 => (0xb7700000) > > > > libedje-ver-svn-05.so.0 => /ESYS/usr/lib/libedje-ver-svn-05.so.0 > > > > (0xb767a000) > > > > libecore_job-ver-svn-05.so.0 => > > > > /ESYS/usr/lib/libecore_job-ver-svn-05.so.0 (0xb7677000) > > > > libecore_file-ver-svn-05.so.0 => > > > > /ESYS/usr/lib/libecore_file-ver-svn-05.so.0 (0xb766e000) > > > > libecore_con-ver-svn-05.so.0 => > > > > /ESYS/usr/lib/libecore_con-ver-svn-05.so.0 (0xb7665000) > > > > libembryo-ver-svn-05.so.0 => > > /ESYS/usr/lib/libembryo-ver-svn-05.so.0 > > > > (0xb765b000) > > > > libecore_imf_evas-ver-svn-05.so.0 => > > > > /ESYS/usr/lib/libecore_imf_evas-ver-svn-05.so.0 (0xb7658000) > > > > libecore_imf-ver-svn-05.so.0 => > > > > /ESYS/usr/lib/libecore_imf-ver-svn-05.so.0 (0xb7652000) > > > > libecore_evas-ver-svn-05.so.0 => > > > > /ESYS/usr/lib/libecore_evas-ver-svn-05.so.0 (0xb763e000) > > > > libecore_fb-ver-svn-05.so.0 => > > > > /ESYS/usr/lib/libecore_fb-ver-svn-05.so.0 (0xb7636000) > > > > libecore_directfb-ver-svn-05.so.0 => > > > > /ESYS/usr/lib/libecore_directfb-ver-svn-05.so.0 (0xb762f000) > > > > libdirectfb-1.4.so.0 => /ESYS/usr/lib/libdirectfb-1.4.so.0 > > > > (0xb75a2000) > > > > libfusion-1.4.so.0 => /ESYS/usr/lib/libfusion-1.4.so.0 > > (0xb7598000) > > > > libdirect-1.4.so.0 => /ESYS/usr/lib/libdirect-1.4.so.0 > > (0xb757f000) > > > > libecore_sdl-ver-svn-05.so.0 => > > > > /ESYS/usr/lib/libecore_sdl-ver-svn-05.so.0 (0xb757a000) > > > > libSDL-1.2.so.0 => /ESYS/usr/lib/libSDL-1.2.so.0 (0xb74c4000) > > > > libvga.so.1 => /usr/lib/libvga.so.1 (0xb7440000) > > > > libecore_input-ver-svn-05.so.0 => > > > > /ESYS/usr/lib/libecore_input-ver-svn-05.so.0 (0xb743b000) > > > > libecore-ver-svn-05.so.0 => > > /ESYS/usr/lib/libecore-ver-svn-05.so.0 > > > > (0xb7410000) > > > > libevas-ver-svn-05.so.0 => /ESYS/usr/lib/libevas-ver-svn-05.so.0 > > > > (0xb7331000) > > > > libfreetype.so.6 => /ESYS/usr/lib/libfreetype.so.6 (0xb72b8000) > > > > libeet.so.1 => /ESYS/usr/lib/libeet.so.1 (0xb72a4000) > > > > libz.so.1 => /lib/libz.so.1 (0xb728e000) > > > > libjpeg.so.7 => /ESYS/usr/lib/libjpeg.so.7 (0xb7257000) > > > > libpthread.so.0 => /lib/tls/i686/cmov/libpthread.so.0 > > (0xb723e000) > > > > libeina-ver-svn-05.so.0 => /ESYS/usr/lib/libeina-ver-svn-05.so.0 > > > > (0xb721a000) > > > > librt.so.1 => /lib/tls/i686/cmov/librt.so.1 (0xb7211000) > > > > libm.so.6 => /lib/tls/i686/cmov/libm.so.6 (0xb71eb000) > > > > libdl.so.2 => /lib/tls/i686/cmov/libdl.so.2 (0xb71e6000) > > > > libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7083000) > > > > libx86.so.1 => /lib/libx86.so.1 (0xb707f000) > > > > /lib/ld-linux.so.2 (0xb7701000) > > > > > > > > > > -- > rgrds, > mobi phil > > being mobile, but including technology > http://mobiphil.com > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [email protected] ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
