From: Mike F. <va...@ge...> - 2004-07-10 01:38:53
|
http://bugs.gentoo.org/show_bug.cgi?id=52634 users were noticing weird results while using Eterm and they tracked it back to libast's MEMSET() macro in eterm/libast/include/libast.h: if (((unsigned long) count) >= 4 * sizeof(long)) { \ /* fill l with c. */ \ l = (c) | (c)<<8; \ l |= l<<16; \ MEMSET_LONG(); the problem being that on 64 bit archs, you'll need a little more << loving ... the patch provided by Jason McCarver is to add another line: l |= l<<32; \ right before the MEMSET_LONG() call http://bugs.gentoo.org/attachment.cgi?id=34976&action=view perhaps the MEMSET_LONG() call itself will need updating ? -mike |
From: Michael J. <e-...@ka...> - 2004-07-14 19:49:49
|
On Friday, 09 July 2004, at 21:38:43 (-0400), Mike Frysinger wrote: > http://bugs.gentoo.org/show_bug.cgi?id=52634 > > users were noticing weird results while using Eterm and they tracked > it back to libast's MEMSET() macro in eterm/libast/include/libast.h: > > if (((unsigned long) count) >= 4 * sizeof(long)) { \ > /* fill l with c. */ \ > l = (c) | (c)<<8; \ > l |= l<<16; \ > MEMSET_LONG(); > > the problem being that on 64 bit archs, you'll need a little more << > loving ... the patch provided by Jason McCarver is to add another line: > l |= l<<32; \ > right before the MEMSET_LONG() call > http://bugs.gentoo.org/attachment.cgi?id=34976&action=view > > perhaps the MEMSET_LONG() call itself will need updating ? If SIZEOF_LONG is set to 8, meaning that a long is a 64-bit value, MEMSET_LONG() is defined to be "l |= l<<32". So the question becomes, what is SIZEOF_LONG being set to? 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) ----------------------------------------------------------------------- "Nerds make the best lovers. That's why I'm in Speed School." -- Angela Smith |
From: Mike F. <va...@ge...> - 2004-07-14 23:35:40
|
On Wednesday 14 July 2004 03:49 pm, Michael Jennings wrote: > If SIZEOF_LONG is set to 8, meaning that a long is a 64-bit value, > MEMSET_LONG() is defined to be "l |= l<<32". So the question becomes, > what is SIZEOF_LONG being set to? configure output: checking size of char... 1 checking size of short... 2 checking size of int... 4 checking size of long... 8 checking size of long long... 8 config.h: amd64 libast-0.5 # grep SIZEOF_ config.h #define SIZEOF_CHAR 1 #define SIZEOF_INT 4 #define SIZEOF_LONG 8 #define SIZEOF_LONG_LONG 8 #define SIZEOF_SHORT 2 -mike |
From: Michael J. <e-...@ka...> - 2004-07-15 00:46:32
|
On Wednesday, 14 July 2004, at 19:35:36 (-0400), Mike Frysinger wrote: > > If SIZEOF_LONG is set to 8, meaning that a long is a 64-bit value, > > MEMSET_LONG() is defined to be "l |= l<<32". > > #define SIZEOF_LONG 8 Okay, then I have to wonder why the #if isn't working.... Check the cpp output and see if MEMSET_LONG() is being defined properly. If not, why not? If so, then why is another line of the same thing needed? 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) ----------------------------------------------------------------------- "I am the only one to blame for this. Somehow it all ends up the same. Soaring on the wings of selfish pride, I flew too high, and like Icarus I collide with a world I tried so hard to leave behind. To rid myself of all but love, to give and die." -- Jars of Clay, "Worlds Apart" |
From: Mike F. <va...@ge...> - 2004-07-15 02:36:33
|
On Wednesday 14 July 2004 08:46 pm, Michael Jennings wrote: > Okay, then I have to wonder why the #if isn't working.... > > Check the cpp output and see if MEMSET_LONG() is being defined > properly. If not, why not? If so, then why is another line of the > same thing needed? i'm going to take a stab here ... feel free to mark me wrong on this :) in libast, the size checks are run and the SIZEOF_* defines are added to the local config.h ... great, so when you actually build libast, it has the proper MEMSET_LONG() macro because it pulls in the local config.h ... however, when Eterm is built, it does not do similar size checks from the configure script and thus has no SIZEOF_* defines ... and since the original config.h from libast was not saved ... when you include libast.h from eterm, SIZEOF_LONG is not defined thus the MEMSET_LONG() macro and the 32 bit shift voodoo is lost :( -mike |
From: Michael J. <e-...@ka...> - 2004-07-15 02:59:09
|
On Wednesday, 14 July 2004, at 22:36:27 (-0400), Mike Frysinger wrote: > in libast, the size checks are run and the SIZEOF_* defines are > added to the local config.h ... great, so when you actually build > libast, it has the proper MEMSET_LONG() macro because it pulls in > the local config.h ... > > however, when Eterm is built, it does not do similar size checks > from the configure script and thus has no SIZEOF_* defines ... and > since the original config.h from libast was not saved ... when you > include libast.h from eterm, SIZEOF_LONG is not defined thus the > MEMSET_LONG() macro and the 32 bit shift voodoo is lost :( Well, shit. See, in libast 0.6, sysdefs.h takes care of making sure these things are defined. libast 0.5, however, doesn't (IIRC). Can you see if this patch fixes the problem? Index: include/libast.h =================================================================== RCS file: /cvsroot/enlightenment/eterm/libast/include/libast.h,v retrieving revision 1.51 diff -u -r1.51 libast.h --- include/libast.h 29 Jun 2004 21:18:07 -0000 1.51 +++ include/libast.h 15 Jul 2004 02:55:40 -0000 @@ -1137,7 +1137,7 @@ #endif /* Fast memset() macro contributed by vendu */ -#if (SIZEOF_LONG == 8) +#if !defined(SIZEOF_LONG) || (SIZEOF_LONG == 8) /** UNDOCUMENTED */ # define MEMSET_LONG() (l |= l<<32) #else Thanks, 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) ----------------------------------------------------------------------- "No weapon formed against us shall prosper. All those who rise against us shall fall. I will not fear what the devil may bring me; I am a servant of God." -- Petra |
From: Mike F. <va...@ge...> - 2004-07-15 03:45:43
|
On Wednesday 14 July 2004 10:59 pm, Michael Jennings wrote: > Well, shit. See, in libast 0.6, sysdefs.h takes care of making sure oh, forgot to ask ... any idea on release dates for next libast/eterm ? ive been watchin cvs commits like a hawk ;) -mike |
From: Mike F. <va...@ge...> - 2004-07-18 01:55:18
|
On Wednesday 14 July 2004 10:59 pm, Michael Jennings wrote: > Can you see if this patch fixes the problem? had the original reporter confirm that your patch fixed it thanks :) -mike |
From: Mike F. <va...@ge...> - 2004-07-15 03:44:15
|
On Wednesday 14 July 2004 10:59 pm, Michael Jennings wrote: > Well, shit. See, in libast 0.6, sysdefs.h takes care of making sure > these things are defined. libast 0.5, however, doesn't (IIRC). Can > you see if this patch fixes the problem? i only have access to a headless amd64 server :) i'll get feedback from some users but chances are it works ... patch is simple enough :) -mike |
From: Michael J. <e-...@ka...> - 2004-07-15 19:11:03
|
On Wednesday, 14 July 2004, at 23:44:12 (-0400), Mike Frysinger wrote: > i only have access to a headless amd64 server :) The only Opteron box I have access to belongs to a customer, so you're better off than I. :) > i'll get feedback from some users but chances are it works ... patch > is simple enough :) I'm hoping so. In any event, I can solve the issue from both sides simply by requiring libast 0.6 for Eterm 0.9.3, but I'd hoped to avoid that. > oh, forgot to ask ... any idea on release dates for next > libast/eterm ? ive been watchin cvs commits like a hawk ;) Well, patches have been coming in here and there, but I think they're both ready to pop...as soon as I can find some time to tackle the releases. You're welcome to move to CVS libast and Eterm; honestly, I'd welcome the advance testing, especially on 64-bit. Rumor hasn't CVS Eterm may not build on AMD64. :-( 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) ----------------------------------------------------------------------- "Don't let them cry. Don't paint me a saint, and don't let them cry." -- Greg Germann, "Ally McBeal" |
From: Michael J. <e-...@ka...> - 2004-07-15 19:32:20
|
On Thursday, 15 July 2004, at 15:10:56 (-0400), I screwed the pooch when I wrote: > Rumor hasn't CVS Eterm may not build on AMD64. :-( That said "Rumor has it." Move along now. Nothing to see here. 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) ----------------------------------------------------------------------- "Don't risk more than you can afford to walk away without." -- Rule of Life #39 |
From: Mike F. <va...@ge...> - 2004-07-22 04:46:14
|
On Thursday 15 July 2004 03:10 pm, Michael Jennings wrote: > You're welcome to move to CVS libast and Eterm; honestly, I'd welcome > the advance testing, especially on 64-bit. Rumor hasn't CVS Eterm may > not build on AMD64. :-( i tried running the autogen script from a cvs checkout on my amd64 box but i just hit a ton of autotool errors ... any chance you could snapshot cvs with autogen already run so i can test it out for you ? -mike |
From: Michael J. <e-...@ka...> - 2004-07-22 20:11:57
|
On Thursday, 22 July 2004, at 00:46:07 (-0400), Mike Frysinger wrote: > i tried running the autogen script from a cvs checkout on my amd64 > box but i just hit a ton of autotool errors ... any chance you > could snapshot cvs with autogen already run so i can test it out for > you ? I'd be happy to. Find me on IRC and I'll DCC you a tarball. But I'm concerned about these auto[fuck] (*grin*) errors. Other than perhaps some underquoted whinings from automake 1.8, there shouldn't be any. :( 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) ----------------------------------------------------------------------- "I don't want this place to get a reputation for buggy software." "Where do you think Microsoft would be if they waited until their products actually worked before they sold them?" -- Mark-Paul Gosselaar and Victor Slezak, "Hyperion Bay" |