Bugzilla Bug 52634

When using Eterm on an AMD64 build with GCC-3.4.0-r1 (atleast that's what I'm
using it may be a more broad problem than that) it does not give the expected
results.  In almost every character slot where there should be a blank space
there is instead a character "ghost box" -- see the linked forum thread for
more details

Reproducible: Always
Steps to Reproduce:
1.Setup an AMD64 based system
2.Emerge Eterm
3.Try to use it

Actual Results:  
Eterm is so ugly it is not really usable

Expected Results:  
A nice to use Eterm

I get the same thing, and it's not limited to GCC-3.4.0-r1.  I'm running GCC
3.3.3  on x86_64 and I get the same thing.

First of all I should have been MUCH more specific.  This is the
x11-terms/eterm I am talking about (not that anyone misunderstood at all, I'm
just trying to clarify)  Next on my agenda is that I found an interesting
behavior that I thought might spark an idea in the head of a more educated
and/or experienced person.  If you launch Eterm and you list the contents of
the current directory (or really just otherwise fill the screen with output so
that you get plenty of these "ghost boxes") then you move another window over
top of it you can "erase" the ghost boxes much like you would use an erase tool
in a drawing program.  Once erased they will easily come back once you try to
interact again with the session in the terminal window.  Not too exciting but I
was surprised by the outcome, and thought it _might_ be helpful.

Hey I am using x.org's release of X windows.  Has anyone tried this on Xfree86
on an AMD64 platform, or has anyone tried Eterm on an x86 platform running
x.org's release?  Maybe we (I) have incorrectly assigned and named this bug. 
Any thoughts?  I will try on x86 with x.org as soon as I can, but I'm doing too
much on my AMD64 right now to bother with testing on it (more than I have to I
mean.)

Regards,
BonezTheGoon

not a gcc-porting bug

Created an attachment (id=34976) [details]
fix in MEMSET macro in libast.h for (at least) AMD64 (64 bit)

I found what I believe to be the problem (it fixes it on my system).  It's the
MEMSET macro in libast.h (installed as /usr/include/libast.h) that eterm uses. 
The macro assumes that a long is no more than 32 bits, when on AMD64 it's 64
bits.

Once this patch has been applied, you must rebuild eterm.

yep, the patch works for me. No more annoying little boxes.

i'll take this upstream then, thanks :)

i've added this patch to libast. it only applies if on a 64bit system for now,
as i havent tested this on a 32bit box :)

I just compiled Eterm in a chroot 32 bit environment with the libast patch.  It
works fine in 32 bit.  It should, the shift operation I added in the patch
should basically do nothing in a 32 bit environment.

This patch works and is now in portage, if you have problems like this with
your Eterm I suggest running an emerge sync and then emerge libast next
re-emerge Eterm.  I am marking this bug fixed.

i havent taken this upstream yet :P

Transparancy doesn't seem to work on x86 either..

Hmmm I don't have any problems with transparency in 64 or 32 bit Eterm (32 bit
chroot x86 environment).  Works fine here.

transparency works fine; sounds like a bug in your settings

could you guys try this patch ?
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

I just tested your changes against libast 0.5-r2 and can confirm that it works
in 64 and 32 bit.  Obviously I didn't look real hard at what was going on in
there ... your fix is the (more) correct solution :)

Sorry it took me awhile to test it ...

Jason

np ... that patch isnt from me, it's from upstream maintainer ...

it really is a kludge around the problem anyways ... the problem is much deeper and has been fixed properly in the upcoming 0.6 release

thanks for confirming it; upstream maintainer just wanted a confirmation :)

Cool.  Just glad to see it fixed ... :)