Hi again,
It's fine now I built eina and evas correctly.
but now I have a problem to compile ecore.
I would like to enable the "evas-directfb" module for ecore but the
configure is behaving in
a stange way here what I did:
$> ./configure --host=sh4-linux --prefix=/home/efl/ecore
--disable-simple-x11 --disable-ecore-evas-software-buffer
--disable-ecore-evas-software-buffer --disable-ecore-evas-software-x11
--disable-ecore-evas-xrender-x11 --disable-ecore-evas-opengl-x11
--disable-ecore-evas-software-16-x11 --disable-ecore-evas-xrender-xcb
--disable-ecore-evas-software-gdi --disable-ecore-evas-software-ddraw
--disable-ecore-evas-direct3d --disable-ecore-evas-opengl-glew
--disable-ecore-evas-software-16-ddraw --disable-ecore-evas-quartz
--disable-ecore-evas-software-sdl --disable-ecore-evas-fb
--disable-ecore-evas-software-16-wince --without-x
disabling all module except the "./configure --host=${target_arch}
--prefix=/opt/STM/STLinux-2.3/devkit/sh4/target/root/rahmanih/efl/ecore
--disable-simple-x11 --disable-ecore-evas-software-buffer
--disable-ecore-evas-software-buffer --disable-ecore-evas-software-x11
--disable-ecore-evas-xrender-x11 --disable-ecore-evas-opengl-x11
--disable-ecore-evas-software-16-x11 --disable-ecore-evas-xrender-xcb
--disable-ecore-evas-software-gdi --disable-ecore-evas-software-ddraw
--disable-ecore-evas-direct3d --disable-ecore-evas-opengl-glew
--disable-ecore-evas-software-16-ddraw --disable-ecore-evas-quartz
--disable-ecore-evas-software-sdl --enable-ecore-evas-directfb
--disable-ecore-evas-fb --disable-ecore-evas-software-16-wince --without-x
I disabled all modules except the "ecore-evas-directfb".
and here what I got in summay:
Core:
Ecore........................: always
Ecore_Job....................: yes
Ecore_Txt....................: yes
Ecore_Con....................: yes
OpenSSL....................: yes (disabled)
GnuTLS.....................: yes
CURL.......................: yes
Abstract Sockets...........: yes
Ecore_Ipc....................: yes
OpenSSL....................: yes (disabled)
GnuTLS.....................: yes
Ecore_File...................: yes
Inotify....................: yes
Poll.......................: yes
CURL.......................: yes
Ecore_Config.................: no
Ecore_IMF....................: yes
Ecore_IMF_Evas...............: yes
Ecore_Input..................: yes
Graphic systems:
Ecore_X (Xlib backend).......: yes
Xcursor....................: yes
Xkb........................: yes
Xprint.....................: no
Xinerama...................: no
Xrandr.....................: yes
Xscreensaver...............: yes
Xrender....................: yes
Xcomposite.................: yes
Xfixes.....................: yes
Xdamage....................: yes
Xdpms......................: yes
Xtest......................: yes
Ecore_Win32..................: no
Ecore_Quartz.................: no
Ecore_SDL....................: no
Ecore_FB.....................: no
Ecore_DirectFB...............: no
Ecore_WinCE..................: no
Ecore Evas:
Ecore_Evas...................: yes
Software Memory Buffer.....: no
Software X11...............: no
XRender X11................: no
OpenGL X11.................: no
XRender XCB................: no
Software GDI...............: no
Software DirectDraw........: no
Direct3D...................: no
OpenGL Glew................: no
Quartz.....................: no
Software SDL...............: no
DirectFB...................: no
Software Framebuffer.......: no
Software 16bit X11.........: no
Software 16bit DirectDraw..: no
Software 16bit WinCE.......: no
but during the "check" phase of the configure I can see the following
messages:
checking whether ecore_x module is to be built... yes
checking whether ecore_evas DirectFB support is to be built... yes
why the ecore_x is getting compiled even if I had disabled it?
and why the summary says that the DirectFB is won't be compiled?
regards.
Haithem.
On Fri, Dec 4, 2009 at 7:37 AM, haithem rahmani
<[email protected]>wrote:
> Hi,
> Thanks indeed.
> Nice to know that EFL are being cross-compiled correclty.I was afraid that
> the build
> system was not tested fro crosscompilation.
>
> keep you informed.
>
> regards.
>
> Haithem.
>
> On Thu, Dec 3, 2009 at 11:42 PM, Carsten Haitzler
> <[email protected]>wrote:
>
>> On Tue, 1 Dec 2009 11:35:28 +0100 haithem rahmani <
>> [email protected]>
>> said:
>>
>> smells to me like something is unclean in your cross-dev environment. as
>> such
>> eina is cross-compiled daily - as is pretty much all of EFL. for ARM
>> mostly,
>> but still - using anything from scratchbox to openemebdded and hand-rolled
>> cross-dev setups. by the look of your output your cross-dev setup is not
>> using
>> a local sh4 target staging directory to find dependencies at all - it's
>> just
>> using the host system. i can't comment beyond that as i dont know your
>> crossdev
>> setup (and to be perfectly honest... it's not our job to fix your setup :)
>> especially if we know it does work on a variety of cross-compiling
>> environments
>> for a variety of targets).
>>
>> so my suggestion is - take a closer look at your cross-compile setup
>> (environement variables, maybe use a chroot for proper isolation or
>> scratchbox2
>> which uses ld_preload tricks etc.)
>>
>> > Hi all,
>> > I'm trying to crosscompile the EFL librairies acutally only eina, evas
>> and
>> > ecore for a "sh4-linux" based platform, but I've got two problems:
>> >
>> > - Eina cross-compiles only with "--disable-shared" otherwise I've got
>> the
>> > following error:
>> >
>> >
>> > /bin/sh ../../../../libtool --mode=install /usr/bin/install -c '
>> > eina_chained_mempool.la'
>> > '/opt/STM/STLinux-2.3/devkit/sh4/target/home/local/efl/lib/eina/mp/
>> > eina_chained_mempool.la'
>> > libtool: install: warning: relinking `eina_chained_mempool.la'
>> > (cd /home//efl/eina-0.0.2.062/src/modules/mp/chained_pool; /bin/sh
>> > ../../../../libtool --tag=CC --tag=disable-static --mode=relink
>> > sh4-linux-gcc -std=gnu99 -O2 -no-undefined -module -avoid-version -o
>> > eina_chained_mempool.la -rpath
>> > /opt/STM/STLinux-2.3/devkit/sh4/target/home/local/efl/lib/eina/mp
>> > eina_chained_mempool_la-eina_chained_mempool.lo ../../../../src/lib/
>> > libeina.la -ldl -lrt -lm -pthread )
>> >
>> > sh4-linux-gcc -shared
>> .libs/eina_chained_mempool_la-eina_chained_mempool.o
>> > -Wl,-rpath
>> -Wl,/opt/STM/STLinux-2.3/devkit/sh4/target/home//local/efl/lib
>> >
>> -L/opt/STM/STLinux-2.3/devkit/sh4/target/opt/STM/STLinux-2.3/devkit/sh4/target/home/local/efl/lib
>> > -leina -ldl -lrt -lm -pthread -Wl,-soname -Wl,eina_chained_mempool.so
>> -o
>> > .libs/eina_chained_mempool.so
>> >
>> >
>>
>> /opt/STM/STLinux-2.3/devkit/sh4/lib/gcc/sh4-linux/4.2.4/../../../../sh4-linux/bin/ld:
>> > cannot find -leina
>> > collect2: ld returned 1 exit status
>> > libtool: install: error: relink `eina_chained_mempool.la' with the
>> above
>> > command before installing it
>> >
>> > - It seems that the "libtool" is using the "LIBTOOL_PREFIX_BASE" twice ?
>> > - why there is this "link command" during the install phase ? is it
>> possible
>> > to move it during the build?
>> >
>> >
>> > - Once Eina built in "static mode" I've problem to build evas : the
>> problem
>> > is related to freetype:
>> >
>> >
>> > /bin/sh ../../libtool --tag=CC --mode=link sh4-linux-gcc -O2
>> > -D_GNU_SOURCE -no-undefined -version-info 9:9:9 -release ver-svn-03 -o
>> > libevas.la -rpath
>> /opt/STM/STLinux-2.3/devkit/sh4/target/home/local/efl/lib
>> > main.lo canvas/libevas_canvas.la file/libevas_file.la
>> > cache/libevas_cache.laimaging/
>> > libevas_imaging.la cserve/libevas_cserve.la engines/common/
>> > libevas_engine_common.la -ldl -lfreetype -lz -lfontconfig -lpthread
>> > -L/opt/STM/STLinux-2.3/devkit/sh4/target/home//local/efl/lib
>> > -leina -lm
>> > /bin/grep: /usr/lib/libfreetype.la: No such file or directory
>> > /bin/sed: can't read /usr/lib/libfreetype.la: No such file or directory
>> > libtool: link: `/usr/lib/libfreetype.la' is not a valid libtool archive
>> >
>> >
>> > any help please ?
>> >
>> > regards.
>> >
>> > Haithem.
>> >
>> ------------------------------------------------------------------------------
>> > Join us December 9, 2009 for the Red Hat Virtual Experience,
>> > a free event focused on virtualization and cloud computing.
>> > Attend in-depth sessions from your desk. Your couch. Anywhere.
>> > http://p.sf.net/sfu/redhat-sfdev2dev
>> > _______________________________________________
>> > enlightenment-users mailing list
>> > [email protected]
>> > https://lists.sourceforge.net/lists/listinfo/enlightenment-users
>> >
>>
>>
>> --
>> ------------- Codito, ergo sum - "I code, therefore I am" --------------
>> The Rasterman (Carsten Haitzler) [email protected]
>>
>>
>
------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
_______________________________________________
enlightenment-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/enlightenment-users
