From: Didier C. <did...@gm...> - 2005-05-30 02:17:59
|
Hi everybody, Somebody just reported that he can't build evas on x86_64 with gcc-4.0.0. Any clues? ---------- Forwarded message ---------- From: John Ellson <el...@re...> Date: May 30, 2005 3:55 AM Subject: Re: Request for review: Enlightenment DR17 + EFL To: Didier Casse <elp...@gm...>, Discussion related to Fedora Extras <fed...@re...> Didier Casse wrote: >Hi all, > I would like to have a review on the Enlightenment DR17 package >+ the accompanying Enlightenment Foundation Library packages (EFL). > > evas fails to build on x86_64 with gcc-4.0.0 /usr/bin/gcc -DHAVE_CONFIG_H -I. -I. -I../../../.. -I/usr/include/freetype2 -mp referred-stack-boundary=3D2 -I/usr/include/valgrind -I/usr/include/valgrind/x86 -I /usr/include/valgrind/linux -I/usr/include/valgrind/x86-linux -I. -I../../../../ src/lib -I../../../../src/lib/include -g -O2 -MT evas_blend_alpha_color_pixel.lo -MD -MP -MF .deps/evas_blend_alpha_color_pixel.Tpo -c evas_blend_alpha_color_pixel.c -fPIC -DPIC -o .libs/evas_blend_alpha_color_pixel.o evas_blend_alpha_color_pixel.c:1: error: -mpreferred-stack-boundary=3D2 is not between 4 and 12 make[5]: *** [evas_blend_alpha_color_pixel.lo] Error 1 make[5]: Leaving directory `/home/ellson/rpmbuild/BUILD/evas-0.9.9.007/src/lib/engines/common' --=20 --=20 With kind regards, Didier. ------------ Yum/apt repository for DR17/EFL: http://sps.nus.edu.sg/~didierbe Didier F.B Casse PhD candidate, Singapore Synchrotron Light Source (SSLS) National University of Singapore. |
From: Tres M. <tr...@mi...> - 2005-05-30 09:09:36
|
On Mon, 2005-05-30 at 15:48 +0900, Carsten Haitzler wrote: > On Sun, 29 May 2005 22:31:19 -0600 Tres Melton <tr...@mi...> babbled: > > > On Mon, 2005-05-30 at 12:53 +0900, Carsten Haitzler wrote: > > > On Mon, 30 May 2005 10:17:52 +0800 Didier Casse <did...@gm...> > > > babbled: > > > > > > > Hi everybody, > > > > Somebody just reported that he can't build evas on > > > > x86_64 with gcc-4.0.0. Any clues? > > > > > > have u checked the CFLAGS? actually READ the error output? evas does NOT set > > > CFLAGs - it inherits from the build environment. gcc is complaining the > > > -mpreferred-stack-boundary=2 is a bad value. it cannot compile the code with > > > it at 2. it must be at 4 to 12. you must fix your CFLAGS > > > > Is it possible to set it to 16 on AMD64? From the gcc manual: > > > > -mpreferred-stack-boundary=num .... > > On Pentium and PentiumPro, "double" and "long double" values should be > > aligned to an 8 byte boundary (see -malign-double) or suffer significant > > run time performance penalties. On Pentium III, the Streaming SIMD > > Extension (SSE) data type "__m128" suffers similar penalties if it is > > not 16 byte aligned. > > ^^ ^^^^ ^^^^^^^ > > I know that the evas engine can use 64 bit MMX xmm registers as I've > > read the code but are there any plans to use the full 128 bit registers? > > And if so would it not be prudent to align the data on 128 bit (16 byte) > > boundaries? > > evas doesnt set it... it ends up valgrind it setting it. as valgrind is x86 only > this conflicts with your arch. Ok, I'm assuming that you are referring to http://valgrind.org/. I feel that I need to point out that SSE is on 32 bit pentium/athalon as well as AMD64. So even though valgrind is x86 there still seems to be some conflict. -- Tres |
From: Didier C. <did...@gm...> - 2005-05-30 16:23:43
|
Dear Developers, Please take a look at the patches and possibly commit them. Thanks cheers, Didier. ---------- Forwarded message ---------- From: John Ellson <el...@re...> Date: May 30, 2005 9:40 PM Subject: Re: Request for review: Enlightenment DR17 + EFL To: Didier Casse <elp...@gm...> Cc: Discussion related to Fedora Extras <fed...@re...> Didier Casse wrote: >On 5/30/05, John Ellson <el...@re...> wrote: > > >>Didier Casse wrote: >> >> >> >>>Hi all, >>> I would like to have a review on the Enlightenment DR17 package >>>+ the accompanying Enlightenment Foundation Library packages (EFL). >>> >>> >>> >>> >>Entrance fails to find -lX11 on x86_64. Should be -L/usr/X11R6/lib64 >>I think the problem is that @X_LIBS@ is not being used from >>AC_PATH_XTRA in configure.in >> >>/usr/bin/gcc -g -O2 -Wall -o entranced auth.o ipc.o md5.o spawner.o >>util.o -L/usr/X11R6/lib -lX11 -lXext -lXau -L/usr/lib64 -lecore >>-lecore_job -lecore_x -lecore_evas -lecore_con -lecore_ipc -lecore_txt >>-lecore_fb -lecore_config -lecore_file -L/usr/lib64 -leet -lz -ljpeg -lm >>-L/usr/lib64 -ledb -lz -lpam -lcrypt >>/usr/bin/ld: cannot find -lX11 >> >> > >--x-libraries=3D{_prefix}/X11R6/{_lib} should be able to fix this. ;-) > > > No, that didn't work. I think the following two changes are needed: --- configure.in.old 2005-05-07 02:01:12.000000000 -0400 +++ configure.in 2005-05-30 09:25:36.000000000 -0400 @@ -199,10 +199,7 @@ AC_DEFINE_UNQUOTED(ENTRANCE_XSESSION, "$xsession", [Xsession script]) AC_SUBST(xsession) -x_cflags=3D"-I/usr/X11R6/include" -x_libs=3D"-L/usr/X11R6/lib -lX11 -lXext" -AC_SUBST(x_cflags) -AC_SUBST(x_libs) +AC_PATH_XTRA EDJE_DEF=3D"" AC_SUBST(EDJE_DEF) --- src/daemon/Makefile.am.old 2005-05-30 09:26:39.000000000 -0400 +++ src/daemon/Makefile.am 2005-05-30 09:20:37.000000000 -0400 @@ -1,6 +1,6 @@ ## Process this file with automake to produce Makefile.in -INCLUDES =3D @x_cflags@ @ecore_cflags@ @edb_cflags@ +INCLUDES =3D @X_CFLAGS@ @ecore_cflags@ @edb_cflags@ sbin_PROGRAMS =3D entranced bin_SCRIPTS =3D entrance_wrapper @@ -8,4 +8,4 @@ entranced_SOURCES =3D \ auth.c auth.h Entranced.h ipc.c ipc.h md5.c md5.h spawner.c util.c util.h -entranced_LDADD =3D @x_libs@ -lXau @ecore_libs@ @edb_libs@ +entranced_LDADD =3D @X_LIBS@ -lX11 -lXext -lXau @ecore_libs@ @edb_libs@ |
From: Corey D. <at...@at...> - 2005-05-30 17:11:47
|
The below patches aren't needed, entrance builds fine on x86_64 and has for some time. If the defaults don't work for you, look into exporting your CFLAGS and LDFLAGS environmental variables so these sort of things get picked up. * Didier Casse (did...@gm...) wrote: > Dear Developers, > Please take a look at the patches and possibly > commit them. Thanks > > cheers, > Didier. > > No, that didn't work. > > I think the following two changes are needed: > > > --- configure.in.old 2005-05-07 02:01:12.000000000 -0400 > +++ configure.in 2005-05-30 09:25:36.000000000 -0400 > @@ -199,10 +199,7 @@ > AC_DEFINE_UNQUOTED(ENTRANCE_XSESSION, "$xsession", [Xsession script]) > AC_SUBST(xsession) > > -x_cflags="-I/usr/X11R6/include" > -x_libs="-L/usr/X11R6/lib -lX11 -lXext" > -AC_SUBST(x_cflags) > -AC_SUBST(x_libs) > +AC_PATH_XTRA > > EDJE_DEF="" > AC_SUBST(EDJE_DEF) > > > --- src/daemon/Makefile.am.old 2005-05-30 09:26:39.000000000 -0400 > +++ src/daemon/Makefile.am 2005-05-30 09:20:37.000000000 -0400 > @@ -1,6 +1,6 @@ > ## Process this file with automake to produce Makefile.in > > -INCLUDES = @x_cflags@ @ecore_cflags@ @edb_cflags@ > +INCLUDES = @X_CFLAGS@ @ecore_cflags@ @edb_cflags@ > > sbin_PROGRAMS = entranced > bin_SCRIPTS = entrance_wrapper > @@ -8,4 +8,4 @@ > entranced_SOURCES = \ > auth.c auth.h Entranced.h ipc.c ipc.h md5.c md5.h spawner.c > util.c util.h > > -entranced_LDADD = @x_libs@ -lXau @ecore_libs@ @edb_libs@ > +entranced_LDADD = @X_LIBS@ -lX11 -lXext -lXau @ecore_libs@ @edb_libs@ > > __ Corey Donohoe http://www.atmos.org |
From: Michael J. <e-...@ka...> - 2005-05-30 17:23:16
|
On Monday, 30 May 2005, at 13:11:37 (-0400), Corey Donohoe wrote: > The below patches aren't needed, entrance builds fine on x86_64 and > has for some time. If the defaults don't work for you, look into > exporting your CFLAGS and LDFLAGS environmental variables so these > sort of things get picked up. Actually, the patches ARE needed. Entrance fails to build properly in numerous situations and has proven to be such a cluster-fuck of a build that I've given up on it multiple times. You really should take these patches; they are behaviorially correct. And far better than what you have now. (You'll note this same bit of code has changed in other packages too, and for much the same reason.) Michael -- Michael Jennings (a.k.a. KainX) http://www.kainx.org/ <me...@ka...> n + 1, Inc., http://www.nplus1.net/ Author, Eterm (www.eterm.org) ----------------------------------------------------------------------- "Greater than the death of flesh is the death of hope, the death of dreams. Against this peril we can never surrender." -- G'Kar, Babylon 5 |
From: Corey D. <at...@at...> - 2005-05-30 18:24:49
|
* Michael Jennings (e-...@ka...) wrote: > On Monday, 30 May 2005, at 13:11:37 (-0400), > Corey Donohoe wrote: > > > The below patches aren't needed, entrance builds fine on x86_64 and > > has for some time. If the defaults don't work for you, look into > > exporting your CFLAGS and LDFLAGS environmental variables so these > > sort of things get picked up. > > Actually, the patches ARE needed. Entrance fails to build properly in > numerous situations and has proven to be such a cluster-fuck of a > build that I've given up on it multiple times. > I don't ever build rpms/debs etc, just build it and throw it in /usr/local No arguments about the cleanliness of the auto* stuff though. :) > You really should take these patches; they are behaviorially correct. > And far better than what you have now. (You'll note this same bit of > code has changed in other packages too, and for much the same reason.) will do > __ Corey Donohoe http://www.atmos.org |
From: John E. <el...@re...> - 2005-05-30 17:29:29
|
Corey Donohoe wrote: >The below patches aren't needed, entrance builds fine on x86_64 and has for >some time. If the defaults don't work for you, look into exporting your >CFLAGS and LDFLAGS environmental variables so these sort of things get >picked up. > > This came up in the discussion of building from src.rpm. I have no CFLAGS or LDFLAGS in my environment, the build gets only those set from the .spec, configure, or Makefiles in the src.rpm. I can assure you that the changes are needed. The hardcoded "-L/usr/X11R6/lib" in configure.in is clearly wrong for x86_64 Fedora-devel. Perhaps you have actually been building a 32 bit version of entrance? John |
From: Corey D. <at...@at...> - 2005-05-30 18:22:14
|
I guess I sorta see why this was working for me, I'm on gentoo not fedora. nemesis% ls -l /usr/X11R6/ | grep lib lrwxrwxrwx 1 root root 5 Mar 29 14:49 lib -> lib64 drwxr-xr-x 7 root root 4096 May 7 02:44 lib32 drwxr-xr-x 83 root root 49152 May 30 13:22 lib64 drwxr-xr-x 6 root root 4096 May 14 09:30 libexec Didier's patches for the daemon/Makefile.am work for you too John ? * John Ellson (el...@re...) wrote: > Corey Donohoe wrote: > > >The below patches aren't needed, entrance builds fine on x86_64 and has for > >some time. If the defaults don't work for you, look into exporting your > >CFLAGS and LDFLAGS environmental variables so these sort of things get > >picked up. > > > > > > This came up in the discussion of building from src.rpm. I have no > CFLAGS or LDFLAGS > in my environment, the build gets only those set from the .spec, > configure, or Makefiles in the src.rpm. > > I can assure you that the changes are needed. The hardcoded > "-L/usr/X11R6/lib" > in configure.in is clearly wrong for x86_64 Fedora-devel. > > Perhaps you have actually been building a 32 bit version of entrance? > > John > > __ Corey Donohoe http://www.atmos.org |
From: Didier C. <did...@gm...> - 2005-05-30 16:26:19
|
Dear developers, Please take a look at the patches and commit if possible, Thanks. cheers, Didier ---------- Forwarded message ---------- From: John Ellson <el...@re...> Date: May 30, 2005 10:41 PM Subject: Re: Request for review: Enlightenment DR17 + EFL To: Didier Casse <elp...@gm...>, Discussion related to Fedora Extras <fed...@re...> Didier Casse wrote: >Hi all, > I would like to have a review on the Enlightenment DR17 package >+ the accompanying Enlightenment Foundation Library packages (EFL). > > Engage fails to rpmbuild on x86_64 Ok the spec patch if for me to apply. Please look at the second one. ;-) Architure dependency in engage.spec: **************************************************************** --- engage.spec.old 2005-05-29 05:32:34.000000000 -0400 +++ engage.spec 2005-05-30 10:35:01.000000000 -0400 @@ -44,7 +44,7 @@ %defattr(-,root,root) %{_bindir}/engage %{_libdir}/engage* -%{_libdir}/enlightenment/modules_extra/engage/linux-gnu-i686/* +%{_libdir}/enlightenment/modules_extra/engage/ %{_datadir}/engage* %doc AUTHORS ChangeLog COPYING README **************************************************************** Improper setting of $libdir in configure.in: **************************************************************** --- engage-0.0.9/configure.in.old 2005-05-30 10:19:31.000000000 -0400 +++ engage-0.0.9/configure.in 2005-05-30 10:20:57.000000000 -0400 @@ -39,6 +39,7 @@ fi fi +if test "x{libdir}" =3D "xNONE"; then if test "x${exec_prefix}" =3D "xNONE"; then if test "x${prefix}" =3D "xNONE"; then libdir=3D"${ac_default_prefix}/lib"; @@ -52,6 +53,7 @@ libdir=3D"${prefix}/lib"; fi fi +fi dnl Set PACKAGE_DATA_DIR in config.h. if test "x${datadir}" =3D 'x${prefix}/share'; then **************************************************************** |
From: Andrew E. <an...@el...> - 2005-05-31 08:27:16
|
seems to me that this is not a patch against a clean CVS co - I cannot see what is new / changed / old Didier Casse wrote: > Dear developers, > Please take a look at the patches and commit > if possible, Thanks. > > cheers, > Didier > > ---------- Forwarded message ---------- > From: John Ellson <el...@re...> > Date: May 30, 2005 10:41 PM > Subject: Re: Request for review: Enlightenment DR17 + EFL > To: Didier Casse <elp...@gm...>, Discussion related to Fedora > Extras <fed...@re...> > > > Didier Casse wrote: > > >>Hi all, >> I would like to have a review on the Enlightenment DR17 package >>+ the accompanying Enlightenment Foundation Library packages (EFL). >> >> > > Engage fails to rpmbuild on x86_64 > > Ok the spec patch if for me to apply. Please look at the second one. ;-) > > Architure dependency in engage.spec: > **************************************************************** > --- engage.spec.old 2005-05-29 05:32:34.000000000 -0400 > +++ engage.spec 2005-05-30 10:35:01.000000000 -0400 > @@ -44,7 +44,7 @@ > %defattr(-,root,root) > %{_bindir}/engage > %{_libdir}/engage* > -%{_libdir}/enlightenment/modules_extra/engage/linux-gnu-i686/* > +%{_libdir}/enlightenment/modules_extra/engage/ > %{_datadir}/engage* > %doc AUTHORS ChangeLog COPYING README > **************************************************************** > > > Improper setting of $libdir in configure.in: > **************************************************************** > --- engage-0.0.9/configure.in.old 2005-05-30 10:19:31.000000000 -0400 > +++ engage-0.0.9/configure.in 2005-05-30 10:20:57.000000000 -0400 > @@ -39,6 +39,7 @@ > fi > fi > > +if test "x{libdir}" = "xNONE"; then > if test "x${exec_prefix}" = "xNONE"; then > if test "x${prefix}" = "xNONE"; then > libdir="${ac_default_prefix}/lib"; > @@ -52,6 +53,7 @@ > libdir="${prefix}/lib"; > fi > fi > +fi > > dnl Set PACKAGE_DATA_DIR in config.h. > if test "x${datadir}" = 'x${prefix}/share'; then > **************************************************************** > > > ------------------------------------------------------- > This SF.Net email is sponsored by Yahoo. > Introducing Yahoo! Search Developer Network - Create apps using Yahoo! > Search APIs Find out how you can build Yahoo! directly into your own > Applications - visit http://developer.yahoo.net/?fr=fad-ysdn-ostg-q22005 > _______________________________________________ > enlightenment-devel mailing list > enl...@li... > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > |
From: Greg R. <ro...@cs...> - 2005-06-04 18:49:20
|
I just spent an hour after updating to e16.8 trying to figure out how to disable the ctrl-alt-a default behavior. I finally found it in the /usr/share/e16/config/bindings.cfg under a heading explaining how they are so well hidden to keep users from accidentally deleting them. This frustrated me. I use enlightenment because it is so configurable and gives me the respect that I know what I'm doing and I'm not going to shoot myself in to foot so I can customize it to the teeth. This secret, almost immutable binding seems to contradict that notion. First, is a keybinding to display everything really that necessary? I've gone quite well without it for years. Second, the keybinding overshadows a particularly useful emacs operation that jumps to the beginning of a c-function. I could remap the emacs command, but I'd rather do away with the enlightenment command I don't use. Finally, yet again, is it really wise to force such keystrokes onto users whether they need them or not? I certainly don't think so. Incidentally, disabling this binding in the aforementioned file does work, but will likely be overwritten the next time I update. Greg Roth |
From: Nathan I. <nin...@gm...> - 2005-06-05 02:33:45
|
Why not put the modified bindings.cfg into ~/.e16 so they don't get overwritten on future installations? On 6/4/05, Greg Roth <ro...@cs...> wrote: > I just spent an hour after updating to e16.8 trying to figure out how to > disable the ctrl-alt-a default behavior. I finally found it in the > /usr/share/e16/config/bindings.cfg under a heading explaining how they > are so well hidden to keep users from accidentally deleting them. >=20 > This frustrated me. I use enlightenment because it is so configurable > and gives me the respect that I know what I'm doing and I'm not going to > shoot myself in to foot so I can customize it to the teeth. This secret, > almost immutable binding seems to contradict that notion. >=20 > First, is a keybinding to display everything really that necessary? I've > gone quite well without it for years. > Second, the keybinding overshadows a particularly useful emacs operation > that jumps to the beginning of a c-function. I could remap the emacs > command, but I'd rather do away with the enlightenment command I don't us= e. > Finally, yet again, is it really wise to force such keystrokes onto > users whether they need them or not? I certainly don't think so. >=20 > Incidentally, disabling this binding in the aforementioned file does > work, but will likely be overwritten the next time I update. >=20 > Greg Roth >=20 >=20 > ------------------------------------------------------- > This SF.Net email is sponsored by: NEC IT Guy Games. How far can you sho= tput > a projector? How fast can you ride your desk chair down the office luge t= rack? > If you want to score the big prize, get to know the little guy. > Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=3D20 > _______________________________________________ > enlightenment-devel mailing list > enl...@li... > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > |
From: Kim W. <ki...@wo...> - 2005-06-05 07:50:27
|
Greg Roth wrote: > I just spent an hour after updating to e16.8 trying to figure out how to > disable the ctrl-alt-a default behavior. I finally found it in the > /usr/share/e16/config/bindings.cfg under a heading explaining how they > are so well hidden to keep users from accidentally deleting them. > > This frustrated me. I use enlightenment because it is so configurable > and gives me the respect that I know what I'm doing and I'm not going to > shoot myself in to foot so I can customize it to the teeth. This secret, > almost immutable binding seems to contradict that notion. > > First, is a keybinding to display everything really that necessary? I've > gone quite well without it for years. > Second, the keybinding overshadows a particularly useful emacs operation > that jumps to the beginning of a c-function. I could remap the emacs > command, but I'd rather do away with the enlightenment command I don't use. > Finally, yet again, is it really wise to force such keystrokes onto > users whether they need them or not? I certainly don't think so. > > Incidentally, disabling this binding in the aforementioned file does > work, but will likely be overwritten the next time I update. > I'm not aware of the history behind why there are these "unchangable" key bindings. I fact, I'm not even sure I like them. However, they have been there "forever", at least back to 0.16.5. The only thing that has changed is the mouse/keybinding configuration file. So, I guess you must have made this tweak once before. Reading README-0.16.8 might have saved you about an hour. /Kim |
From: John E. <el...@re...> - 2005-05-30 18:29:12
|
Corey Donohoe wrote: >I guess I sorta see why this was working for me, I'm on gentoo not fedora. > >nemesis% ls -l /usr/X11R6/ | grep lib >lrwxrwxrwx 1 root root 5 Mar 29 14:49 lib -> lib64 >drwxr-xr-x 7 root root 4096 May 7 02:44 lib32 >drwxr-xr-x 83 root root 49152 May 30 13:22 lib64 >drwxr-xr-x 6 root root 4096 May 14 09:30 libexec > >Didier's patches for the daemon/Makefile.am work for you too John ? > > Sorry for the confusion - the patches came from me originally. On Fedora there is no softlink lib -> lib64. Both 32bit and 64 bit applications coexist on the system. John |
From: Corey D. <at...@at...> - 2005-05-30 21:16:52
|
patches are in, thx. * John Ellson (el...@re...) wrote: > Corey Donohoe wrote: > > >I guess I sorta see why this was working for me, I'm on gentoo not fedora. > > > >nemesis% ls -l /usr/X11R6/ | grep lib > >lrwxrwxrwx 1 root root 5 Mar 29 14:49 lib -> lib64 > >drwxr-xr-x 7 root root 4096 May 7 02:44 lib32 > >drwxr-xr-x 83 root root 49152 May 30 13:22 lib64 > >drwxr-xr-x 6 root root 4096 May 14 09:30 libexec > > > >Didier's patches for the daemon/Makefile.am work for you too John ? > > > > > Sorry for the confusion - the patches came from me originally. > > On Fedora there is no softlink lib -> lib64. Both 32bit and 64 bit > applications > coexist on the system. > > John __ Corey Donohoe http://www.atmos.org |
From: Didier C. <did...@gm...> - 2005-05-31 14:10:14
|
On 5/31/05, John Ellson <el...@re...> wrote: > Corey Donohoe wrote: >=20 > >I guess I sorta see why this was working for me, I'm on gentoo not fedor= a. > > > >nemesis% ls -l /usr/X11R6/ | grep lib > >lrwxrwxrwx 1 root root 5 Mar 29 14:49 lib -> lib64 > >drwxr-xr-x 7 root root 4096 May 7 02:44 lib32 > >drwxr-xr-x 83 root root 49152 May 30 13:22 lib64 > >drwxr-xr-x 6 root root 4096 May 14 09:30 libexec > > > >Didier's patches for the daemon/Makefile.am work for you too John ? > > > > > Sorry for the confusion - the patches came from me originally. >=20 Yeah the patches are John Ellson's patches. ;-) I'm sorry if i didn't make that clear. --=20 --=20 With kind regards, Didier. ------------ Yum/apt repository for DR17/EFL: http://sps.nus.edu.sg/~didierbe Didier F.B Casse PhD candidate, Singapore Synchrotron Light Source (SSLS) National University of Singapore. |
From: Greg R. <ro...@cs...> - 2005-06-05 06:53:13
|
Nathan Ingersoll wrote: > Why not put the modified bindings.cfg into ~/.e16 so they don't get > overwritten on future installations? > I'd have said that the modified binding constitutes a removal rather than an addition so it's not something I'm trying to add rather damage I'm trying to remove. I would also have suspected that the user config wouldn't have allowed changes to that Action class. Still, to convince myself and mostly to prove you wrong I tried copying the entire Action class section into ~/.e16/e_config.bindings: Aclass KEYBINDINGS_UNCHANGABLE global #KeyDown CA a button_show all KeyDown CA b button_show KeyDown CA c button_show buttons CONFIG* KeyDown CA d desk dragbar dir KeyDown CA o desk dragbar order To my surprise, it worked. It's an functional solution. I don't like it, but it gets the job done. Thanks for suggesting something I would have rejected had I thought to try it myself. Greg |
From: Greg R. <ro...@cs...> - 2005-06-05 15:11:34
|
> Reading README-0.16.8 might have saved you about an hour. > > /Kim > *groan* Quite right. There it is. All the information I needed. I'm not sure how I overlooked that. Greg |
From: John E. <el...@re...> - 2005-05-30 04:44:31
|
Didier Casse wrote: > >Btw what happens when you disable mmx and sse for evas? Does it >compile on your architecture? > > > Didn't fix it. Carsten Haitzler (The Rasterman) wrote: >have u checked the CFLAGS? actually READ the error output? evas does NOT set >CFLAGs - it inherits from the build environment. gcc is complaining the >-mpreferred-stack-boundary=2 is a bad value. it cannot compile the code with it >at 2. it must be at 4 to 12. you must fix your CFLAGS > > OK. The -mpreferred-stack-boundary=2 came from /usr/lib/pkgconfig/valgrind.pc which I picked up because I had /usr/lib/pkgconfig in my PKG_CONFIG_PATH and there is no 64 bit version of valgrind in the fedora-devel distribution. I fixed it locally by using only /usr/lib64/pkgconfig in my PKG_CONFIG_PATH. My fault I guess. "rpmbuild -ba evas.spec" is now working for me on x86_64. John |
From: Carsten H. (T. R. <ra...@ra...> - 2005-05-30 03:54:19
|
On Mon, 30 May 2005 10:17:52 +0800 Didier Casse <did...@gm...> babbled: > Hi everybody, > Somebody just reported that he can't build evas on > x86_64 with gcc-4.0.0. Any clues? have u checked the CFLAGS? actually READ the error output? evas does NOT set CFLAGs - it inherits from the build environment. gcc is complaining the -mpreferred-stack-boundary=2 is a bad value. it cannot compile the code with it at 2. it must be at 4 to 12. you must fix your CFLAGS > > ---------- Forwarded message ---------- > From: John Ellson <el...@re...> > Date: May 30, 2005 3:55 AM > Subject: Re: Request for review: Enlightenment DR17 + EFL > To: Didier Casse <elp...@gm...>, Discussion related to Fedora > Extras <fed...@re...> > > Didier Casse wrote: > > >Hi all, > > I would like to have a review on the Enlightenment DR17 package > >+ the accompanying Enlightenment Foundation Library packages (EFL). > > > > > evas fails to build on x86_64 with gcc-4.0.0 > > /usr/bin/gcc -DHAVE_CONFIG_H -I. -I. -I../../../.. > -I/usr/include/freetype2 -mp referred-stack-boundary=2 > -I/usr/include/valgrind -I/usr/include/valgrind/x86 -I > /usr/include/valgrind/linux -I/usr/include/valgrind/x86-linux -I. > -I../../../../ src/lib -I../../../../src/lib/include -g -O2 -MT > evas_blend_alpha_color_pixel.lo -MD -MP -MF > .deps/evas_blend_alpha_color_pixel.Tpo -c > evas_blend_alpha_color_pixel.c -fPIC -DPIC -o > .libs/evas_blend_alpha_color_pixel.o > evas_blend_alpha_color_pixel.c:1: error: -mpreferred-stack-boundary=2 is > not between 4 and 12 > make[5]: *** [evas_blend_alpha_color_pixel.lo] Error 1 > make[5]: Leaving directory > `/home/ellson/rpmbuild/BUILD/evas-0.9.9.007/src/lib/engines/common' > > > > -- > -- > With kind regards, > Didier. > > ------------ > Yum/apt repository for DR17/EFL: http://sps.nus.edu.sg/~didierbe > > Didier F.B Casse > PhD candidate, Singapore Synchrotron Light Source (SSLS) > National University of Singapore. > > > ------------------------------------------------------- > This SF.Net email is sponsored by Yahoo. > Introducing Yahoo! Search Developer Network - Create apps using Yahoo! > Search APIs Find out how you can build Yahoo! directly into your own > Applications - visit > http://developer.yahoo.net/?fr_______________________________________________ > enlightenment-devel mailing list > enl...@li... > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ra...@ra... 裸好多 ra...@de... Tokyo, Japan (東京 日本) |