weird g++ behavior
greetings all, a few months ago, i made the great leap of faith and switched to debian (woody) from suse -- a few false starts, but all in all i'm still convinced it was a good choice, if only... my problem is that i'm getting a whole slew of intermittent, unreproducable (but nonetheless frequently occurring) errors only under woody -- most frequent is weirdness from g++, which occasionally tells me for instance: configure:2797: g++ -c -g -O2 -I/usr/local/include/stlport conftest.cc >&5 In file included from /usr/local/include/stlport/stl/_num_put.h:178, from /usr/local/include/stlport/stl/_ostream.c:29, from /usr/local/include/stlport/stl/_ostream.h:349, from /usr/local/include/stlport/stl/_istream.h:31, from /usr/local/include/stlport/stl/_fstream.h:34, from /usr/local/include/stlport/fstream:33, from configure:2792: /usr/local/include/stlport/stl/_num_put.c:292: parse error before `*' ... and other such joyful messages -- when the syntax is in fact perfectly kosher (/usr/local/include/stlport is just a symlink to /usr/include/stlport, for (temporary, i hope) compatibility with my suse system). i get this and similar errors (almost always "parse error before `*'" in many of my own sources (frequently changed and recompiled); often it's a line such as SomeRandomClass *c1, *c2, ..., *cN; causing the error (N >= 2) -- usually, re-invoking 'make' causes the same file to compile just fine. a self-compiled gcc-2.95.3 produced the same errors on woody. crap like this is why i stopped using windoof; i always though gcc was a pretty damn stable compiler... put this together with a mess of odd filesystem errors (on ext2/ext3), and i get a really bad feeling... suse (heavily modified v7.1) gives me neither the g++ errors nor the filesystem errors. memory and other hardware problems i therefore deem improbable... does anyone have any ideas what i might try? System: chipset: VIA apollo cpu: Athlon 1Ghz ram: 768 MB ... complete hardware list on request; but i really don't think it can be pure hardware problem... marmosets, Bryan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: weird g++ behavior
On 21 November 2002 at 09:08:27, Elizabeth Barham wrote: > I had somewhat similar problems with some standard libraries > (libstdc++, libc, etc.) accidentally left in /usr/local after upgrading > to woody. Removing the libraries and executables remedied the > situation. > > Elizabeth hmm, i don't think this can be it either -- woody is installed on a clean partition, and i still get problems without anything but / mounted... upgrading to the libc6 from the 'woody-proposed-updates' subtree also failed to help. argh, but thanks anyways! marmosets, Bryan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: weird g++ behavior
hi Elizabeth, On 21 November 2002 at 11:30:10, Elizabeth Barham wrote: > What about running conftest.cc through the pre-processor with the "-E" > option (g++ -E ...)? That often helps clear up some of the odder parse > errors. > > Elizabeth yes, i also find it a good way to diagnose weird preprocessor errors: the thing is, chances are that the bug won't manifest on the next call -- two or three files down the line g++ will crash again either with a bogus "parse error before `*'" or just silently fail... i suppose i could script a stress-test to keep re-running the preprocess/compile stages until one of them breaks, and then look at the output, but the intermittent character and the other problems make me suspect it's not just a gcc/g++/cpp bug... marmosets, Bryan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
VT82C686B Sound Problem
hi Robert, i have an "Elitegroup" mainboard with the same chipset on it, which i've managed to get sound out of using the alsa drivers (http://www.alsa-project.org) ; also under kernel 2.4.19, using the alsa-0.9.0 series (0.9.0-rc?)... i'm not clear on the "official" debian procedure for building alsa -- you need to rebuild it whenever you install a new kernel at any rate, the alsa 'card' for this chipset is called something like "via686a"... marmosets, Bryan Robert James Kaes wrote: > Hi, > I have a MSI KT7 Pro2-A motherboard with a vt82c686b chipset. It has an > onboard sound card. I've been trying to get the sound to work, but > without any success. I'm running a 2.4.19-386 kernel on a "testing" > distro. I tried the vt82cxxx_audio.o driver without any luck, so I > decided to download the drivers from VIA Technologies at: > > http://www.viaarena.com/?PageID=128 > > I downloaded the 68audio_Linux_package1.16.zip file and tried to follow > the instructions. However, they do not have any information for Debian > (although, there is information for SuSE, Redhat, etc.) > > Has anyone either got these drivers to work with Debian using a 2.4.19 > kernel, or is there another driver I should be using to activate the > onboard sound system. > > Any information you can provide would be appreciated. > -- Robert -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: VT82C686B Sound Problem
Steve Juranich wrote: > On Fri, 22 Nov 2002 13:48:58 -0500, Robert James Kaes wrote: > > > Has anyone either got these drivers to work with Debian using a 2.4.19 > > kernel, or is there another driver I should be using to activate the > > onboard sound system. > > I'm using the same mobo/sound setup. I'm using 2.4.18 kernel with ALSA. > I'm able to both play back and record just fine, but there's some > wonkiness that I have to run the gnome mixer applet after each reboot to > turn the soundcard back on. I think that the ALSA package is secretly > shutting things off for shutdown and then never restores them to > previous values on the reboot. This is something I've been meaning to > look into, but I'm not bothered with it right now. 'alsactl store' and 'alsactl restore' ? marmosets, Bryan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
2^n (was: weird g++ behavior)
hi Elizabeth, hi list, first of all, thanks for your suggestions, Elizabeth -- a 'crashme.sh' script was in fact very helpful... turns out, the machine (same procedure on another box ran fine) crashed g++ only with my 256MB ram-bar in slot-0 and my 512MB bar in slot-1 ... go figure. each bar alone: kosher. also, things appear fine when the 512MB bar precedes its less capacitous cousin. argh. i can definitely live with this, but can anyone explain to me why this must be so? (mainboard/bios bug is my personal guess, but i'm truly stumped...) did some goofball go and assume that everyone on the planet has 2^n bytes of ram?or is it just a swing-a-dead-chicken- over-your-head-at-midnight-on-a-new-moon-whilst- invoking-eldritch-and-mystic-powers sort of thing? argh, peace, love, and marmosets, moocow ps - another odd diagnostic (for the record): from the old SuSE installation: suse# chroot /debian crashme.sh also produced the errors... whereas SuSE itself never had any problems with the compilation that weren't my fault ;-) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: GNU-LINUX Installation!
greetings, On 22 November 2002 at 18:21:18, Samaad Story wrote: > > Hello guys i am familiar with computers etc, But I am not at all familiar with >installing Linux. Im am not to sure about the partitioning of the hard drive, the >bios, and basically the entire process of installing this OS. I have some of the >information on your web site but still am a little confused, if you can help it would >be of a great service to me. Also if you have any great books that you can think of >that would better my knowledge of Linux it would be greatly appreciated as well. >Thank you for your time. > > Best Regards, > > Samaad Story well, i read this ca. 7 years ago and have never looked back... http://www.ibiblio.org/pub/Linux/docs/linux-doc-project/users-guide/ it's pretty strongly geared towards slackware, but the basics (paritioning, etc.) are well presented and pretty universal (at least for linux/x86). marmosets, Bryan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: 2^n (was: weird g++ behavior)
On 22 November 2002 at 21:14:00, Michael Heironimus wrote: > > or is it just a swing-a-dead-chicken- > > over-your-head-at-midnight-on-a-new-moon-whilst- > > invoking-eldritch-and-mystic-powers sort of thing? > > It could be a board/BIOS problem, or it could be that one of those two > modules has a minor problem that only shows up in one particular > configuration. It's actually not entirely surprising that this ended up > being a memory issue, gcc is good at finding memory problems. Usually > they cause random aborts or core dumps, though, not syntax > complaints i've had memory problems before (different system), and they showed up already with mke2fs... made the linux install rather difficult ;-) > If you have time it might be to your advantage to go ahead and run a > real memory test. If one of those modules does have a problem you'd be > better off finding out now instead of later when it causes some other > strange problem. If you can't run a real memory test some people suggest > recompiling the kernel 10-20 times without interruption, the kernel code > is complex enough that it sometimes causes errors where other code > doesn't. i agree that a real test would be a good thing -- actually, the machine ran memtest86 for 2.5 days (ca. 7 tests) without reporting any errors: is there any other "real" memory tester you'd reccommend? i've compiled about 5 kernels by now on that installation without any problems -- it's the g++/STL strangeness that seems to bite me most reliably... mamrosets, Bryan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
