Re: [E-devel] Compile Problem with e,entice,entrance,e_utils
So is my gcc wrong ? zol:~$ cpp --version cpp (GCC) 3.3.3 Copyright (C) 2003 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. --- Carsten Haitzler <[EMAIL PROTECTED]> a écrit : > On Sat, 27 Aug 2005 00:02:23 +0200 (CEST) zol > <[EMAIL PROTECTED]> babbled: > > > Hye Rasterman, > > > > wi th -mfpmath=387 that's the same thing : > > that option will affect binaries compiled - not > edjes. it seesm your CPP it > doing weird things we don't expect it to do. > > > gcc -g -O2 -mfpmath=387 -o entice entice.o image.o > > ipc.o keys.o prefs.o signals_image.o > signals_thumb.o > > exif.o main.o > > -L/usr/local/E17/lib > > /usr/local/E17/lib/libesmart_container.so > > -L/usr/local/lib -L/usr/X11R6/lib > /usr/local/lib/liblt > > dl.so /usr/local/E17/lib/libesmart_draggies.so > > -L/home/zol/e17/libs/ecore/src/lib/ecore/.libs > > -L/home/zol/e17/libs/eco > > re/src/lib/ecore_txt/.libs > > -L/home/zol/e17/libs/ecore/src/lib/ecore_job/.libs > > -L/home/zol/e17/libs/ecore/src/lib/ecore > > _x/.libs > > -L/home/zol/e17/libs/ecore/src/lib/ecore_fb/.libs > > /usr/local/E17/lib/libesmart_thumb.so > > /usr/local/E17/lib/li > > bepsilon.so -L/usr/local/ssl/lib > > -L/home/zol/e17/libs/ecore/src/lib/ecore_con/.libs > > /usr/local/E17/lib/libepeg.so /usr > > /local/E17/lib/libesmart_trans_x11.so > > /usr/local/E17/lib/libImlib2.so > > /usr/X11R6/lib/libfreetype.so /usr/local/E17/lib > > /libedje.so /usr/local/E17/lib/libecore_evas.so > > /usr/local/E17/lib/libecore_x.so -lXcursor -lXp > > -lXinerama /usr/local/ > > E17/lib/libecore_job.so > > /usr/local/E17/lib/libecore_txt.so > > /usr/local/E17/lib/libecore_fb.so > > /usr/local/E17/lib/libeco > > re_config.so /usr/local/E17/lib/libecore_ipc.so > > /usr/local/E17/lib/libevas.so > > /usr/local/lib/libfreetype.so -lpng /usr > > /local/E17/lib/libedb.so > /usr/local/lib/libXCBImage.so > > /usr/local/lib/libXCBICCCM.so > > /usr/local/lib/libXCBAtom.so /usr > > /local/lib/libXCBProperty.so > > /usr/local/lib/libXCBEvent.so > /usr/local/lib/libXCB.so > > /usr/local/lib/libXau.so /usr/loca > > l/lib/libdirectfb.so /usr/lib/libGL.so -lX11 > -lXext > > -lGL -lGLU -lpthread > > /usr/local/E17/lib/libecore_file.so /usr/loca > > l/E17/lib/libecore_dbus.so > > /usr/local/E17/lib/libecore_con.so > > /usr/local/E17/lib/libecore.so > > /usr/local/lib/libcurl.so > > -lssl -lcrypto -ldl /usr/local/E17/lib/libeet.so > -lz > > /usr/local/lib/libjpeg.so > > /usr/local/E17/lib/libembryo.so -lm -l > > c > > make[3]: Leaving directory > > `/home/zol/e17/apps/entice/src/bin' > > make[3]: Entering directory > > `/home/zol/e17/apps/entice/src' > > make[3]: Nothing to be done for `all-am'. > > make[3]: Leaving directory > > `/home/zol/e17/apps/entice/src' > > make[2]: Leaving directory > > `/home/zol/e17/apps/entice/src' > > make[1]: Leaving directory > > `/home/zol/e17/apps/entice/src' > > Making all in data > > make[1]: Entering directory > > `/home/zol/e17/apps/entice/data' > > Making all in themes > > make[2]: Entering directory > > `/home/zol/e17/apps/entice/data/themes' > > Making all in default > > make[3]: Entering directory > > `/home/zol/e17/apps/entice/data/themes/default' > > Making all in parts > > make[4]: Entering directory > > > `/home/zol/e17/apps/entice/data/themes/default/parts' > > make[4]: Nothing to be done for `all'. > > make[4]: Leaving directory > > > `/home/zol/e17/apps/entice/data/themes/default/parts' > > Making all in programs > > make[4]: Entering directory > > > `/home/zol/e17/apps/entice/data/themes/default/programs' > > make[4]: Nothing to be done for `all'. > > make[4]: Leaving directory > > > `/home/zol/e17/apps/entice/data/themes/default/programs' > > make[4]: Entering directory > > `/home/zol/e17/apps/entice/data/themes/default' > > edje_cc -v -id ../../../data/images -fd > > ../../../data/fonts default.edc default.eet > > edje_cc: Opening "/tmp/edje_cc.edc-tmp-7GTktI" for > > input > > edje_cc: Parsing input file > > edje_cc: Error. parts/bg.edc:1 got 2 arguments, > but > > expected 1 > > make[4]: *** [default.eet] Error 255 > > make[4]: Leaving directory > > `/home/zol/e17/apps/entice/data/themes/default' > > make[3]: *** [all-recursive] Error 1 > > make[3]: Leaving directory > > `/home/zol/e17/apps/entice/data/themes/default' > > make[2]: *** [all-recursive] Error 1 > > make[2]: Leaving directory > > `/home/zol/e17/apps/entice/data/themes' > > make[1]: *** [all-recursive] Error 1 > > make[1]: Leaving directory > > `/home/zol/e17/apps/entice/data' > > make: *** [all-recursive] Error 1 > > > > > > > > ??? evas_list_count (params) != required_args > > where's my problem > > > > > > > > > > > > > > > ___ > > > Appel audio GRATUIT partout dans le monde avec le > nouveau Yahoo! Messenger > > T$(D+1l$(D+1chargez cette version sur
Re: [E-devel] Compile Problem with e,entice,entrance,e_utils
On Sat, 27 Aug 2005 10:12:23 +0200 (CEST) zol <[EMAIL PROTECTED]> babbled: > > So is my gcc wrong ? something about your gcc is making its preprocessor add spaces i think. thats my best guess. before only apple's gcc did this. > > zol:~$ cpp --version > cpp (GCC) 3.3.3 > Copyright (C) 2003 Free Software Foundation, Inc. > This is free software; see the source for copying > conditions. There is NO > warranty; not even for MERCHANTABILITY or FITNESS FOR > A PARTICULAR PURPOSE. > > --- Carsten Haitzler <[EMAIL PROTECTED]> a écrit : > > > On Sat, 27 Aug 2005 00:02:23 +0200 (CEST) zol > > <[EMAIL PROTECTED]> babbled: > > > > > Hye Rasterman, > > > > > > wi > th -mfpmath=387 that's the same thing : > > > > that option will affect binaries compiled - not > > edjes. it seesm your CPP it > > doing weird things we don't expect it to do. > > > > > gcc -g -O2 -mfpmath=387 -o entice entice.o image.o > > > ipc.o keys.o prefs.o signals_image.o > > signals_thumb.o > > > exif.o main.o > > > -L/usr/local/E17/lib > > > /usr/local/E17/lib/libesmart_container.so > > > -L/usr/local/lib -L/usr/X11R6/lib > > /usr/local/lib/liblt > > > dl.so /usr/local/E17/lib/libesmart_draggies.so > > > -L/home/zol/e17/libs/ecore/src/lib/ecore/.libs > > > -L/home/zol/e17/libs/eco > > > re/src/lib/ecore_txt/.libs > > > -L/home/zol/e17/libs/ecore/src/lib/ecore_job/.libs > > > -L/home/zol/e17/libs/ecore/src/lib/ecore > > > _x/.libs > > > -L/home/zol/e17/libs/ecore/src/lib/ecore_fb/.libs > > > /usr/local/E17/lib/libesmart_thumb.so > > > /usr/local/E17/lib/li > > > bepsilon.so -L/usr/local/ssl/lib > > > -L/home/zol/e17/libs/ecore/src/lib/ecore_con/.libs > > > /usr/local/E17/lib/libepeg.so /usr > > > /local/E17/lib/libesmart_trans_x11.so > > > /usr/local/E17/lib/libImlib2.so > > > /usr/X11R6/lib/libfreetype.so /usr/local/E17/lib > > > /libedje.so /usr/local/E17/lib/libecore_evas.so > > > /usr/local/E17/lib/libecore_x.so -lXcursor -lXp > > > -lXinerama /usr/local/ > > > E17/lib/libecore_job.so > > > /usr/local/E17/lib/libecore_txt.so > > > /usr/local/E17/lib/libecore_fb.so > > > /usr/local/E17/lib/libeco > > > re_config.so /usr/local/E17/lib/libecore_ipc.so > > > /usr/local/E17/lib/libevas.so > > > /usr/local/lib/libfreetype.so -lpng /usr > > > /local/E17/lib/libedb.so > > /usr/local/lib/libXCBImage.so > > > /usr/local/lib/libXCBICCCM.so > > > /usr/local/lib/libXCBAtom.so /usr > > > /local/lib/libXCBProperty.so > > > /usr/local/lib/libXCBEvent.so > > /usr/local/lib/libXCB.so > > > /usr/local/lib/libXau.so /usr/loca > > > l/lib/libdirectfb.so /usr/lib/libGL.so -lX11 > > -lXext > > > -lGL -lGLU -lpthread > > > /usr/local/E17/lib/libecore_file.so /usr/loca > > > l/E17/lib/libecore_dbus.so > > > /usr/local/E17/lib/libecore_con.so > > > /usr/local/E17/lib/libecore.so > > > /usr/local/lib/libcurl.so > > > -lssl -lcrypto -ldl /usr/local/E17/lib/libeet.so > > -lz > > > /usr/local/lib/libjpeg.so > > > /usr/local/E17/lib/libembryo.so -lm -l > > > c > > > make[3]: Leaving directory > > > `/home/zol/e17/apps/entice/src/bin' > > > make[3]: Entering directory > > > `/home/zol/e17/apps/entice/src' > > > make[3]: Nothing to be done for `all-am'. > > > make[3]: Leaving directory > > > `/home/zol/e17/apps/entice/src' > > > make[2]: Leaving directory > > > `/home/zol/e17/apps/entice/src' > > > make[1]: Leaving directory > > > `/home/zol/e17/apps/entice/src' > > > Making all in data > > > make[1]: Entering directory > > > `/home/zol/e17/apps/entice/data' > > > Making all in themes > > > make[2]: Entering directory > > > `/home/zol/e17/apps/entice/data/themes' > > > Making all in default > > > make[3]: Entering directory > > > `/home/zol/e17/apps/entice/data/themes/default' > > > Making all in parts > > > make[4]: Entering directory > > > > > > `/home/zol/e17/apps/entice/data/themes/default/parts' > > > make[4]: Nothing to be done for `all'. > > > make[4]: Leaving directory > > > > > > `/home/zol/e17/apps/entice/data/themes/default/parts' > > > Making all in programs > > > make[4]: Entering directory > > > > > > `/home/zol/e17/apps/entice/data/themes/default/programs' > > > make[4]: Nothing to be done for `all'. > > > make[4]: Leaving directory > > > > > > `/home/zol/e17/apps/entice/data/themes/default/programs' > > > make[4]: Entering directory > > > `/home/zol/e17/apps/entice/data/themes/default' > > > edje_cc -v -id ../../../data/images -fd > > > ../../../data/fonts default.edc default.eet > > > edje_cc: Opening "/tmp/edje_cc.edc-tmp-7GTktI" for > > > input > > > edje_cc: Parsing input file > > > edje_cc: Error. parts/bg.edc:1 got 2 arguments, > > but > > > expected 1 > > > make[4]: *** [default.eet] Error 255 > > > make[4]: Leaving directory > > > `/home/zol/e17/apps/entice/data/themes/default' > > > make[3]: *** [all-recursive] Error 1 > > > make[3]: Leaving directory > > > `/home/zol/e17/apps/entice/data/themes/default' > > > make[2]: *** [all-recursive] Error 1 > > > make[2]: Leaving directory > > > `/home/zol/e17/apps/entice/data/themes' > > > make[1]
Re: [E-devel] patch - imlib2 blend in AMD64
Sorry for the delay in the response.. Well, I tested it again and really, just putting the alignment in the .text segment didn't work. I then changed all the remaining movdqa (only the %rip ones sure), because I'm almost sure that they would also give problems. The change involved at most 3 instructions per call, so the performance impact as you noted should be totally negligible. The patch is attached, if someone could please put it in CVS I think that the matter is closed then. Thanks, and thanks also for the info about up relative addressing, Tiago On Thu, 2005-08-25 at 03:33 -0600, John Slaten wrote: > Hmmm. That should have worked. > Basically, what ip relative addressing does is make the code position > independent. When the assembler sees an instruction like that, it makes > the offset (mX000X000X000X00) equal to the offset from the next > instruction in the code to the specified data, so that no matter where > the program is located in memory, the data can always be found right at > the same spot. > I don't know why forcing the alignment did not make the program work. > I suppose that the only solution then is to change all of the (%rip) > movdqa instructions to movdqu - if the changes are kept to the > ip-relative ones, the performance impact should be minimal as these are > only executed once per function call. > > On Thu, 2005-08-25 at 06:44 +, Tiago Victor Gehring wrote: > > Hi, > > thanks for the info and help - nothing like hearing from who wrote the > > code... > > I then applied your patch and put the original lines back, with the > > aligned copy, but I now get again the same problem as before, > > segmentation faults.. > > The first line that gives me problem is #570, this is a piece of the > > code so you can find it: > > > > LEAVE > > SIZE(imlib_amd64_blend_rgba_to_rgb) > > PR_(imlib_amd64_blend_rgba_to_rgba): > > ENTER > > > > pxor %xmm4, %xmm4 > > movdqa c1(%rip), %xmm5 -> *** here's the first problem > > xorq %rax, %rax > > movdqa mX000X000X000X000(%rip), %xmm6 > > movq [EMAIL PROTECTED](%rip), %r13 > > > > And I confirmed that now I compiled it with the ".align 16" in the .text > > segment.. > > And just being curious now, could you perhaps explain what does a > > instruction like the above does? I mean, what does the "mask" in front > > of the %rip does, you take the address of the next instruction, apply > > (AND) a mask and move it to %xmm5? Sorry, just curious... > > > > Thanks, > > Tiago > > > > > > > > On Wed, 2005-08-24 at 18:45 -0600, John Slaten wrote: > > > > > > > > Since I wrote the original code, I thought I'd weigh in on this. > > > > > > 1. The memory that is causing the errors is statically allocated data in > > > the .text segment, which I assumed would be correctly aligned and forgot > > > to supply the .align directive. Adding this (as in the attached patch) > > > _should_ fix the problem, though I have not tried to reproduce/test it. > > > The code should then work with the aligned instructions as in the > > > original. > > > 2. The existing code jumps through quite a lot of hoops to make best use > > > of the aligned instructions. For instance, when it encounters an odd > > > pixel address, it will process a single pixel at the start of the loop > > > to force alignment for the destination address (which uses both read and > > > write, and is thus more important). In fact, due to the possiblity of > > > odd scanline pitch, the alignment is checked at the start of each > > > scanline, and the correct instructions are used accordingly. > > > 3. The code was built to handle weird input that is only 1 byte aligned. > > > Thus, it should handle any alignment that is thrown at it, and if it > > > doesn't that's a bug, but it should be fixable. > > > 4. I don't recall the exact statistics, but I ran tests on aligned vs > > > unaligned instructions while I was writing the code, and using the > > > aligned instructions gives a large speed boost. I think it was about > > > 20%, but I might be wrong. The key is that movdqa is a double path > > > instruction and movdqu is a vector path instruction, and double path > > > instructions are a whole lot quicker than vector path ones. > > > > > > > > > > > > > > > ___ > > Yahoo! Acesso Grtis - Internet rpida e grtis. > > Instale o discador agora! http://br.acesso.yahoo.com/ > > > > > > > > --- > > SF.Net email is Sponsored by the Better Software Conference & EXPO > > September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices > > Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA > > Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf > > ___ > > enlightenment-devel mailing list > > enlightenment-devel@lists.sourceforge.net > >
Re: [E-devel] Summary of my e17 compile on Mac OS X 10.4
Sebastian Dransfeld wrote: Ulrich Hobelmann wrote: Sebastian Dransfeld wrote: Library is the set of directories where aclocal check for its files. The file it doesn't find is called 'gettext.m4'. Hm, I have /usr/local/share/aclocal/gettext.m4 and lots of other files in that directory. There's also /usr/share/aclocal, but that shouldn't be the problem I guess... /usr/local sounds standard to me If automake is installed in /usr, it doesn't search /usr/local: http://www.delorie.com/gnu/docs/automake/automake_19.html Just try to add -I /usr/local/share/aclocal to aclocal or define ACLOCAL_PATH The path didn't do anything, but setting ACLOCAL_FLAGS worked. Unfortunately now gcc barfs: e $ make cd . && /bin/sh /Users/ulli/e17/apps/e/missing --run autoheader touch ./config.h.in cd . && /bin/sh ./config.status config.h config.status: creating config.h config.status: config.h is unchanged make all-recursive Making all in src Making all in bin source='e_main.c' object='e_main.o' libtool=no \ depfile='.deps/e_main.Po' tmpdepfile='.deps/e_main.TPo' \ depmode=gcc3 /bin/sh ../../depcomp \ gcc -DHAVE_CONFIG_H -I. -I. -I../.. -I/usr/local/include -I../.. -I../../src/bin -I../../src/lib -I/usr/local/include -I/usr/local/include -I/usr/local/include -I/usr/local/include -I/usr/local/include -I/usr/X11R6/include -I /System/Library/Frameworks/CoreFoundation.framework/Headers -I /System/Library/Frameworks/IOKit.framework/Headers -DLOWRES_PDA=1 -DMEDIUMRES_PDA=2 -DHIRES_PDA=3 -DSLOW_PC=4 -DMEDIUM_PC=5 -DFAST_PC=6 -DE17_PROFILE=FAST_PC -I/usr/local/include -O2 -c `test -f 'e_main.c' || echo './'`e_main.c In file included from e.h:30, from e_main.c:4: /usr/local/include/Ecore_Config.h:63: error: parse error before numeric constant make[3]: *** [e_main.o] Error 1 make[2]: *** [all-recursive] Error 1 make[1]: *** [all-recursive] Error 1 make: *** [all] Error 2 Line 63 looks harmless to me, maybe the gcc 4.0.0 (that Apple installs on their systems) has some infancy problems... --- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
