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.
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
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
---
This SF.Net email is sponsored by BEA Weblogic Workshop
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
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/ [EMAIL PROTECTED]
n + 1,
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 *
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 |= l32. So the question becomes,
what is SIZEOF_LONG being set to?
configure output:
checking size of char... 1
checking size of
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 |= l32.
#define SIZEOF_LONG 8
Okay, then I have to wonder why the #if isn't working
Check the cpp output and see
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
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 ...
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
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
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; \
13 matches
Mail list logo
