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 attachment 34976 [details, diff] 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 ... :)
