> Does any of this crap show up in linux, particularly the x86 flavors?
Yes. I have not had any luck getting the current source to compile. I've
seen most of the problems you're describing. As a matter of fact the problem
you had with/near ParseColor is pretty close to the problem that I saw when
I was running the code under MSVC6.0.
Lemme comb over that function again to make sure there is nothing stange
going on.
But, yes, I've seen these problems before. At first I thought it was a
config issue on my machine, but now that does not seem to be the case. Yeah.
Have you tried gcc 2.95-pre2? I think that is what Isaac is running....
--ruaok Freezerburn! All else is only icing. -- Soul Coughing
Robert Kaye -- [EMAIL PROTECTED] http://moon.eorbit.net/~robert
----- Original Message -----
From: Tom Spindler <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, October 08, 1999 3:23 PM
Subject: sigh.
> Well, it looks like there are some rather nasty lurking bugs in
> gcc-2.95.1; bugs that popped up when things were compiled with -O2 went
> away when compiled with -O; I'm beginning to suspect that the alias
> analysis code is a bit stricter than a lot of programmers out there.
>
> Anyway, I was getting crashes in code Theme.cpp in ParseColor, when
> I inserted the extra lines (@845)
>
> char *foo = oColorstring.c_str();
> printf("colors: %s; ocolor: %lx", foo, &oColor);
>
> And then the crashing stopped; unfortunately, the printf never showed
> itself, and the crash has occured deeper in the code in GTK/glib land:
>
> (gdb) bt
> #0 0xff2fdd74 in XGetWindowAttributes () from
/usr/openwin/lib/libX11.so.4
> #1 0xfe3dcae8 in gdk_window_foreign_new (anid=0) at gdkwindow.c:508
> #2 0xfe2ce478 in GTKBitmap::GTKBitmap (this=0x171198, oName=@0x99a9c)
> at ui/theme/unix/src/GTKBitmap.cpp:59
> #3 0xfe2a2294 in Theme::BeginElement (this=0x16d2c4,
oElement=@0xffbe34f0,
> oAttrMap=@0xffbe33f0) at ui/theme/src/Theme.cpp:296
> #4 0x4ff94 in Parse::DoParse (this=0x16d2c4) at lib/xml/src/Parse.cpp:225
> #5 0x4efcc in Parse::ParseFile (this=0x16d2c4, oFile=@0xffbe38d0)
> at lib/xml/src/Parse.cpp:61
> #6 0xfe2a0748 in Theme::LoadTheme (this=0x16d2c4, oFile=@0xffbe3b08)
> at ui/theme/src/Theme.cpp:155
> #7 0xfe2c0254 in FreeAmpTheme::LoadFreeAmpTheme (this=0x16d2c0)
> at ui/theme/src/FreeAmpTheme.cpp:151
> #8 0xfe2bfb10 in FreeAmpTheme::FreeAmpTheme (this=0x16d2c0,
context=0x966f0)
> at ui/theme/src/FreeAmpTheme.cpp:83
> #9 0xfe2bf72c in Initialize (context=0x966f0)
> at ui/theme/src/FreeAmpTheme.cpp:59
> #10 0x3243c in Player::Run (this=0x98708) at base/src/player.cpp:645
> #11 0x49508 in main (argc=709, argv=0xffbe3f44)
> at base/unix/src/bootstrap.cpp:132
>
> the last bit of code that's in freeamp proper is frame #3,
>
> #3 0xfe2a2294 in Theme::BeginElement (this=0x16d2c4,
oElement=@0xffbe34f0,
> oAttrMap=@0xffbe33f0) at ui/theme/src/Theme.cpp:296
> 296 pBitmap = new GTKBitmap(oAttrMap["Name"]);
>
> Which isn't inspiring confidence in me.
>
> At this point, I'm thinking of trying the egcs-current source, and
> seeing if those mollify any bugs; it looks like the bleeding-edge
> template stuff is causing gcc (or me, for that matter) to not be a
> Happy Boy. (The fact that linkage problems mysteriously go away
> with -fsquangle do not fill me with joy, either.)
>
>
