Subject: Linux-Development Digest #532 From: Digestifier To: Linux-Development@senator-bedfellow.MIT.EDU Reply-To: Linux-Development@senator-bedfellow.MIT.EDU Date: Wed, 9 Mar 94 08:13:05 EST Linux-Development Digest #532, Volume #1 Wed, 9 Mar 94 08:13:05 EST Contents: Re: Help! GCC errors (Dave Gardner) Re: program runs fine in xxgdb, but not in xterm! (Frohwalt Egerer) Re: AMD 486DX problem (with Linux?) (Gregory McKesey) write() on a tty with O_NONBLOCK set (was Re: pre1.0 strange behaviour) (J. Cowley) Re: write() on a tty with O_NONBLOCK set (was Re: pre1.0 strange behaviour) (Laurent Chemla) Who's doing the Macintosh port of Linux? (Nick B Triantos) USing PPP or CLSIP through stupid terminal servers (James Lathrop) Problems with AHA-1542CF after correct Installation (Friedrich Kink) Re: gcc internal compiler error - SIGSE [2~ [2SEGV (Cord Johannmeyer) Re: Small pre-1.0 problem (Kevin Lentin) Re: Small pre-1.0 problem (Kevin Lentin) select (Frank McCabe) dip for PPP when? (Robert Stockmann) Re: TTY overruns cost money. (Peter Busser) Loaded fonts discarded after X vt switch... (Ray Bellis) Re: Specialix driver (Alan Cox) Re: UDP report card (Alan Cox) Re: gcc internal compiler error - SIGSE[2~[2SEGV (Rob Janssen) Re: Small pre-1.0 problem (Rob Janssen) ---------------------------------------------------------------------------- From: dgardner@netcom.com (Dave Gardner) Subject: Re: Help! GCC errors Date: Tue, 8 Mar 1994 21:21:40 GMT Rob Janssen (rob@pe1chl.ampr.org) wrote: : You must have missed that this newsgroup is about "Ongoing work on the : Linux operating system", not about asking questions. That largely explains : the attitude towards people asking questions anyway, especially when they : are so clearly answered in the read.me file that came with the package : that they are asking about... Yes, Rob, I'm sure we could all pick nits for hours and hours, belaboring all sorts of points (I can easily see one in your paragraph above which I could question). However, a quick, polite pointer to either an faq or an appropriate newsgroup would have saved tons of bandwidth on this issue. Instead, we've got a lot of people up in a later over what should really be a minor issue. The fact is, there is a persistent bad attitude among some folks here in Linuxland, one which is repelling rather than attracting new users. Perhaps they got trashed when they jumped on the bandwagon, and now they're passing down the legacy to future generations. Perhaps they're just cranky people. I don't know. But this useless "fun" of cutting (or trying to, anyway) newbies to ribbons is just plain pointless and completely counterproductive. Questions, inappropriate and otherwise, are not going to stop. Like it or not, as more folks try to join the legions of Linux, there are bound to be continual pleas for help, and there will be continuous inappropriate posting. One can either choose to help the cause, either by polite answer via email or a polite public prod to the appropriate place, or if you can't do that, than by hitting the 'n' key and moving on. No one helps promote Linux -- much less any product, large or small -- by insulting new users, of which one can only hope (for Linux's sake) there will be an endless supply. -- ============================================================================== Dave Gardner \ / The views expressed in this message are entirely dgardner@netcom.com -*- my own. I speak for no one else, and no one S. Pasadena, CA / \ else speaks for me .... I think. ============================================================================== ------------------------------ From: froh@devnull.adsp.sub.org (Frohwalt Egerer) Subject: Re: program runs fine in xxgdb, but not in xterm! Date: Wed, 9 Mar 1994 02:36:32 GMT Manoj Kasichainula (mvkasich@eos.ncsu.edu) wrote: : OK, here's the situation. I'm trying to do a program for my data : structures class at home. I've appended a copy of it below to look at. : When I run the program at the command line prompt, it immediately exits : and sets $status to 1. But when I run it in xxgdb, it runs fine, except : for some necessary debugging 8^). Why is the program not doing anything : when run at the command line prompt? No I'm not asking someone to debug : the program, just please explain why it doing what it's doing. Oh yeah, : when I run the program on the DECstations at college, it works fine. : Thanks in advance. I think the bug is in ttwinner.c: : -----ttwinner.c----- : #include "ttwinner.h" : int winner(Board board) : { : int winning = 1, whowins, i = 0; : whowins = board[BOARDSIZE/2]; : for (;i < BOARDSIZE / 2 - 1; i++) : winning = winning && (board[i] == whowins) : && (board[BOARDSIZE - 1 - i] == whowins); : return (winner && whowins); ~~~~~~ *HERE* : } : ----end ttwinner.c---- This statement takes the address of the 'winner' function. It probably is a typo, I assume there should be 'winning'. Since you perform a _logical_ and between winner and whowins you may get false (0) or true (any random nonzero value). The exact value of the result probably depends on the adress of the 'winner' function, which is different if your programs runs under control of the debugger or if it doesn't. An other machine (the DECstation) will place the 'winner' function at an other address, too. When winner returns some arbitrarily values, there is a simple reason why the program just returns $status 1: : ----- tttest.c (main program) ----- ... : int main(void) : { : while ((winner(board) == DRAW) && (nummoves != BOARDSIZE)) : { : } : if (winner(board) == HUMAN) : puts("You won, it wasn't that hard since you made all the moves"); : if (winner(board) == COMPUTER) : puts("I won, obviously a result of my suprior intellect."); : if (winner(board) == DRAW) : puts("You played all the moves, and you could still only manage a tie!"); : } If winner(board) returns some random value, which is different from DRAW, HUMAN and COMPUTER, neither the while loop nor any of the if statements will be executed. main() will just be left, without any return value set. When none is set, some random value is used (what- ever is left in some processor register or the memory) ( BTW: If you use gcc compile with the -Wall switch. gcc will then emit a warning 'control reaches end of non-void function' which means the same as 'you forgot to add a return() to this function' ) It is advisable to use assert in all your programs, since it will help you find bugs like these. assert() terminates the program and reports the source file and line number if the expression passed to it evaluates false. ASSERT: ( Include at the top of the program. ) : if (winner(board) == HUMAN) : puts("You won, it wasn't that hard since you made all the moves"); : if (winner(board) == COMPUTER) : puts("I won, obviously a result of my suprior intellect."); : if (winner(board) == DRAW) : puts("You played all the moves, and you could still only manage a tie!"); assert( winner(board)==HUMAN || winner(board)==COMPUTER || winner(board)==DRAW ); I learned to use assert() the hard way: Debugging programs some people wrote, that are literally computer illiterate. (No pun intended) Using assert() often helps much to draw one's attention to the real bug. Froh -- Frohwalt Egerer Drausnickstr. 36 91052 Erlangen Germany /// Use froh@devnull.franken.de (preferred) /// Linux ftegerer@cip.informatik.uni-erlangen.de \\\/// \XX/ ECG 210 Meiner ist grv_er als Deiner! -- Henning Schmiedehausen beim Karlsruhe Meeting 94 ------------------------------ From: mckesey@imaphics.prior.com (Gregory McKesey) Subject: Re: AMD 486DX problem (with Linux?) Date: 08 Mar 1994 21:43:41 GMT >>>>> "Hans" == Hans Christoph Rohland writes: : Anyways, I was hoping that someone else with an AMD 486DX : could verify that this is an AMD problem (or whether it is just : limited to me :( ). If someone also had another OS/Compiler : combination to ensure that this is not just a AMD486DX/GCC/Linux : problem. Hans> This is obviously no AMD Problem! I get a similar error with Hans> an Intel 486DX66 (Linux 0.99.15 from Slack 1.1.2). The Hans> testprogram for AMD works fine but ghostview gives the Hans> following error: Hans> Unrecoverable error: typecheck in setstrokeadjust Operand Hans> stack: 0.988235 0.992157 0.996078 1.0 true Hans> gs sometimes works, sometimes failes... Perhaps it has Hans> something to do with the swapping mechanism? I always run Hans> with low memory when starting ghostview... I managed to get ghostscript to work by recompiling it with the -msoft-float option. This is not ideal but it works. Greg. -- ____________________________________________________________________ Gregory McKesey (Software Manager) Gallium Software Inc. Tel: (613)721-0902 ext (431) 303 Moodie Dr., Suite 4000 Fax: (613)721-1278 Nepean, Ontario, Canada. gmckesey@gallium.com K2H-9R4 ==================================================================== ------------------------------ From: julian@uhunix.uhcc.hawaii.edu (J. Cowley) Subject: write() on a tty with O_NONBLOCK set (was Re: pre1.0 strange behaviour) Date: Wed, 9 Mar 1994 06:30:15 GMT In article <2ldcmn$3o@brasil.fr.mugnet.org>, Laurent Chemla wrote: Now the bad news. I'm writing a program that places the text cursor where it wants on the screen. Stdin is in O_NONBLOCK mode, but stdout is not. The cursor does no more react the same way it was used to until I upgrade from pl15h to ALPHA1.0. You say that stdout doesn't have O_NONBLOCK set, but I'm pretty sure that it does. The reason why I say that is that getty_ps and agetty, two of the most popular getty's, create stdout and stderr from stdin using dup(). That means that if you set O_NONBLOCK on stdin, it will also be set on stdout and stderr. You must be using one of these two getty's, or one that works similarly. AND, more importantly! As of pl15i, if you write() to a tty, O_NONBLOCK is set, and not all of the data could be queued for transmission, the write() will not block and will return how many characters it was able to queue. This will be less than the requested amount, and is what's known as a "partial write". If no characters could be queued, write() will return -1 and set errno to EAGAIN. Previous kernels ignore O_NONBLOCK, so partial writes don't happen and you don't get this behavior. This seems to be causing problems somewhere, either in the stdio code (most likely) or in your program. NOTE that it does work allright on the console screen, but it just seems to be fooled on any of my serial terminals, at any speed. If i'm on ttyS4 (for instance) and then just enter 'myprogram' then it doesn't work, but if I enter 'myprogram > /dev/ttyS4' then it does work! A 'stty -a' shows that rows and columns are set to 0 when I log in on a serial terminal, but it always did. And when I enter a 'tset' command, rows and columns are correct but it doesn't change anything. The change to the handling of O_NONBLOCK is more likely to affect serial lines than consoles. The reason is that when requested by the write() code, consoles can always transmit the requested data to the screen. Serial lines, on the other hand, can initially transmit only as much as the UART's buffer is willing to hold, and this can be as little as one byte. The kernel notices that not all the requested data was transmitted, and attempts to block until the serial driver indicates that the data was finally written to the device. If O_NONBLOCK is set, it won't block and causes a partial write. The reason why it works when you use a '>' is that the tty is opened from scratch, so it doesn't have O_NONBLOCK set. In fact, as a workaround for your program, fopen() /dev/tty and use that instead of stdout. Or turn off O_NONBLOCK while you're not reading from the tty. -=- julian ------------------------------ From: root@brasil.frmug.fr.net (Laurent Chemla) Subject: Re: write() on a tty with O_NONBLOCK set (was Re: pre1.0 strange behaviour) Date: 9 Mar 1994 08:46:49 GMT J. Cowley (julian@uhunix.uhcc.hawaii.edu) wrote: : You say that stdout doesn't have O_NONBLOCK set, but I'm pretty : sure that it does. The reason why I say that is that getty_ps : and agetty, two of the most popular getty's, create stdout and : stderr from stdin using dup(). That means that if you set : O_NONBLOCK on stdin, it will also be set on stdout and stderr. : You must be using one of these two getty's, or one that works : similarly. You're absolutely right! After some digging I found those new lines in the write_chan() kernel routine, so I must admit my stdout is set O_NONBLOCK. : AND, more importantly! As of pl15i, if you write() to a tty, : O_NONBLOCK is set, and not all of the data could be queued for : transmission, the write() will not block and will return how many : characters it was able to queue. This will be less than the : requested amount, and is what's known as a "partial write". If : no characters could be queued, write() will return -1 and set : errno to EAGAIN. : Previous kernels ignore O_NONBLOCK, so partial writes don't : happen and you don't get this behavior. You're right again, but the point is my program doesn't use write() at all. It only uses fputc() and fputs() calls, and those calls can't test EAGAIN as this condition may occurs anywhere during the flush of the previous 1024 bytes that were sent. So the question becomes "Should I allways explicitely open my tty using non-blocking I/O if I want to use those calls, or should the library handle this trick, always using non-blocking I/O when outputing data though putchar(), putc(), fputc(), fputs() etc.. ?". I'm not a good C programmer. In fact, I'm an Atari "assembler only" programmer :-) so please don't flame me if this question is not a good one. Just tell me. Laurent. -- Laurent Chemla laurent@brasil.frmug.fr.net Brasil BBS - +33 1 44 67 08 44 - Atari France developpers support. ------------------------------ From: triantos@netcom9.netcom.com (Nick B Triantos) Subject: Who's doing the Macintosh port of Linux? Date: Wed, 9 Mar 1994 09:25:54 GMT I hate to post this to all the net, but I'm interested in helping with the port of Linux to the Macintosh platforms (680x0 and/or PowerPC). I didn't see an address in the FAQ that I could email to. Anyway, if you're working on that project, or know who might be, please email me. Thanks, Nick Triantos triantos@netcom.com triantos@claris.com ------------------------------ From: jil@cs.iastate.edu (James Lathrop) Subject: USing PPP or CLSIP through stupid terminal servers Date: 8 Mar 94 07:05:12 GMT Ok I have an idea and I'm just checking to see if anyone else has done this. The situation is this. Our terminal server escapes codes 13 17 19 141 143 145 147 and 155, making slip or PPP useless. I can run term thorugh this connection and get upload rates of 1650 cps on binary files using term's compression with a 14400 modem. (I don;t know why this is since I think gzip does a good job at compressing files.) SO here is the idea. Modify trshell so that you can login and start up ppp on the remote machine. pppd will take over the pseudo tty just fine and output junk to term and it will show up on your local temrinal. Then modify trshell so that if it receives a special escape code it will open a master and slave pty and just exachange infor coming from terms port with the tty master. Then you can run ppd on your local machine and give the pty that you opened in the modified trshell. PPP or slip for that matter can then run in clean 8-bit mode and never see the terminal server. Sure there will be a few bytes wasted using term, but term;s compression seems pretty good, and I wouldn;t mind the slow down to say 1600 cps. (-: If someone has done anything like this, please send me E-mail right away. I am going to start work on this project a week from today and would rather not duplicate any work. --- Jim ------------------------------ From: kink@sun60.bau.FH-Aachen.de (Friedrich Kink) Subject: Problems with AHA-1542CF after correct Installation Date: 9 Mar 1994 10:36:46 GMT Reply-To: kink@sun60.bau.FH-Aachen.de Hallo everybody outthere without having problems :-) First I have no problems to install the Adaptec Controller. There are two harddisk drives which are wellknown to the controller. After booting Linux the harddisks are mountable and work with them seems normal. The only problem that I have occures if I try to copy files to the drives. The error occures on changing positions therefore it is unpredictable wether the filecontens is the same as in the original or not. The copy methods are rcp, ftp, via nfs or only cp on the same drive. The datasize is about 70Megs. Sometimes the computer hangs during the copy process. It isn't then possible to kill the process and the following reboot process sometimes hangs too. Under DOS the controller drive combination works marvelous. I don't know is it a electrical problem (cable etc.) or problem with the filesystem or a problem with settings on contoller or drive (soft or hard) or a problem with myself. My configuration: 486DX/33 VL 8MB RAM SMC Ultra Card ET4000 Graphics Card AT-Bus Controller with 1.44M floppy drive and 210M Seagate HD drive ST3243A AHA-1542CF Controller BIOS v2.01 Drive #0 IBM 0662S12 SCSI-2 Drive #1 HP 97548SP SCSI-1 CCS Fritz Kink EMAIL: kink@sun60.bau.fh-aachen.de Fachhochschule Aachen VOICE: [Germany] 24160091115 Bayernallee 9 FAX: [Germany] 24160091480 52066 Aachen ------------------------------ From: cord@kalliope.atlas.de (Cord Johannmeyer) Subject: Re: gcc internal compiler error - SIGSE [2~ [2SEGV Date: 9 Mar 1994 10:06:42 GMT Christopher Andrew Smith (z1g192@rick.cs.ubc.ca) wrote: : I'm getting an error that I've never seen before when compiling a certain : appliction. What happens is that after I've compiled all the object files : for the application and start linking the application with the library : I made, gcc reports an internal error which I've never encountered before. [deleted] : gcc: Internal compiler error: program ld got fatal signal 11 : make: *** [app] Error 1 : Has anyone else ever had this problem? I'd like to know if it is a common : problem. I've had this problem some time ago, it was caused by a Hardware failure, but i don't remember what. So carefully check your hardware. Cord -- ______________________________________________________________________________ | Atlas Elektronik GmbH D-28305 Bremen | | Cord Johannmeyer Simulation Division Sebaldsbruecker Heerstr. 235 | | +49/421/457-3179 -3177 fax | |_________________ jhm@atlas.de ________________________________________| ------------------------------ From: kevinl@bruce.cs.monash.edu.au (Kevin Lentin) Subject: Re: Small pre-1.0 problem Date: 9 Mar 1994 00:41:33 GMT On Tue, 8 Mar 1994 17:05:05 GMT, Achim Oppelt wrote: > I assume you are using getty_ps, which interprets certain @-character > sequences and replaces them with things like hostname, number of users > logged in etc. @k is probably not defined, so it is simply stripped. > (I cannot check this out since I currently do not have acces to my > Linux box, which is at home in Germany :-( ) > So this has nothing to do with pre-1.0. So it would seem, but I am CONVINCED that I had never seen ths behaviour until pre-1.0 was installed. And my getty has not changed. -- [==================================================================] [ Kevin Lentin |___/~\__/~\___/~~~~\__/~\__/~\_| ] [ kevinl@bruce.cs.monash.edu.au |___/~\/~\_____/~\______/~\/~\__| ] [ Macintrash: 'Just say NO!' |___/~\__/~\___/~~~~\____/~~\___| ] [==================================================================] ------------------------------ From: kevinl@bruce.cs.monash.edu.au (Kevin Lentin) Subject: Re: Small pre-1.0 problem Date: 9 Mar 1994 00:43:11 GMT On Tue, 8 Mar 1994 22:27:36 GMT, Rob Janssen wrote: > >So this has nothing to do with pre-1.0. > Indeed. Just use the output of "uname -a" instead of the /proc/version > file... Or I could sed out what I don't want, or as I have done, replaced the @ with an @@ - sed to the rescue. It really doesn't matter one way or the other. My point was that, as far as I can determine, I saw this the first time when I installed pre-1.0 and my getty has not changed. -- [==================================================================] [ Kevin Lentin |___/~\__/~\___/~~~~\__/~\__/~\_| ] [ kevinl@bruce.cs.monash.edu.au |___/~\/~\_____/~\______/~\/~\__| ] [ Macintrash: 'Just say NO!' |___/~\__/~\___/~~~~\____/~~\___| ] [==================================================================] ------------------------------ From: fgm@doc.ic.ac.uk (Frank McCabe) Subject: select Date: 9 Mar 94 11:05:30 GMT I have come across an apparent problem with the select system call. According to the specification, if select is given a non-zero timeout then the system call is supposed to wait for the appropriate interval before terminating. Well it doesnt! If you give a non-zero timeout the nit comes back immediately. I know that this is not my problem, because the same (i.e. identical) program behaves as expected on a sun sparc under suno 4.1.13. Are there any known fixes for this? Frank McCabe ------------------------------ From: stock@dutsh7.tudelft.nl (Robert Stockmann) Subject: dip for PPP when? Date: Wed, 9 Mar 1994 09:17:23 GMT Hello, After looking at dip , I noticed that there is an option for choosing PPP as protocol. however looking at the ppp.c routine it gives a message that its not implemented yet. When will this be? is someone working on it? The main advantage of dip over chat is that the script language is much more flexible, which is important when one wants to connect with PPP after a call back from a PPP server. robert stockmann ------------------------------ From: peter@globv1.hacktic.nl (Peter Busser) Subject: Re: TTY overruns cost money. Date: Tue, 8 Mar 1994 13:33:20 GMT tgm@netcom.com (Thomas G. McWilliams) writes: >Nemosoft Unv. (nemosoft@void.tdcnet.nl) wrote: >: The significance of that being that even at that low speed, input >: overruns make my computer useless. The solution is to pull out the modem and >: thus hang up the connection, causing serial communication to stop :-(. > [ stuff deleted ] > >: All serial ports are 16450s. Oh yeah: even with overruns, I don't loose >: data. >Your solution is to get a 16550 UART. Let's get real now! For 1 line at 2400bps noone needs a 16550 UART. Heck, even MS-Windoze will work without it on a slow computer... Groetjes, Peter Busser -- Linux, the choice of a GNU generation. ------------------------------ From: rpb@psy.ox.ac.uk (Ray Bellis) Subject: Loaded fonts discarded after X vt switch... Date: 09 Mar 1994 11:35:59 GMT I've noticed that if I use setfont to change the console font, then use X Windows, the loaded font is discarded and the standard font reinstalled. Does anyone have any idea how we might modify the kernel to restore the loaded font after switching out of a graphics vt? Thanks, Ray. p.s., I've made a load of fonts suitable for use with setfont from the vga/fontpak.zip file on simtel20. Anyone have recommendations for where I should put them? -- ============================================================================== R. P. Bellis E-Mail: Dept. of Experimental Psychology Whois: (RB83) University of Oxford Tel: +44 865 271419 South Parks Road Fax: +44 865 310447 Oxford OX1 3UD ============================================================================== ------------------------------ From: iiitac@swan.pyr (Alan Cox) Subject: Re: Specialix driver Date: Wed, 9 Mar 1994 09:58:38 GMT In article <1994Mar7.213931.21744@brtph560.bnr.ca> denebeim@bnr.ca (Jay Denebeim P025) writes: >In article <1994Mar1.143313.25803@swan.pyr> iiitac@swan.pyr (Alan Cox) writes: >>It would be OK I guess, not ideal and I don't like it - I certainly wouldn't >>buy the card. > >Why? Does this mean you've got the source to your BIOS ROM? How >about the ROM on your video card? (hey, if you've got a Diamond, I >bet there's a bunch of people who would like to talk to you) If not, >why is this card any different? Well actually no.. That got take out of context of the other half of the discussion (I should have quoted more). I wouldn't buy it because I don't think smart serial boards are cost effective compared with just using 16550A UARTS and upping your motherboard spec. > >I don't know anything about the card that you ended up with, does it >have an on-board processor? Do you have the source code for that, or >do you just know what its interface is? If its the latter you're >getting exactly what the guy from digiboard is offering. Now I am aware that they were talking about the generic on board kernel then I see no problem, as I said in another message. In fact this is the same as some modems running under Linux. Alan iiitac@pyr.swan.ac.uk ------------------------------ From: iiitac@swan.pyr (Alan Cox) Subject: Re: UDP report card Date: Wed, 9 Mar 1994 10:12:39 GMT In article <2lj8f2$gis@access1.digex.net> christop@access1.digex.net (Chris Anderson) writes: >Three things seem kinda odd: > >1. A sendto INADDR_ANY as a destination gives me a ENETUNREACH. This errno is > new for me, in other environments the local process bound to either the > loopback or one of the machine's inet addresses gets the message. INADDR_ANY is counted as a broadcast address in Linux. Which is where this is coming from. Earlier pl15 systems also mistakenly return ENETUNREACH not EACCESS as BSD does for broadcast write without having set SO_BROADCAST. I wasn't aware that a sendto() of INADDR_ANY had a special semantic in BSD. I'll check this. > >2. A sentto destination of my local address when there isn't a process bound > to it, returns a ECONNREFUSED. I've never encountered this behavior before. BSD only does this for 'fatal' errors. The internet RFC's are fairly specific that _all_ ICMP errors ought to be reported to the end user process. I'm still open to comments on this one, but security considerations certain favour following the RFC not BSD code. If you want BSD behaviour then change inet/udp.c:udp_err() so the line sk->err = icmp_error_convert[err & 0xff].errno; has if(icmp_error_convert[err&0xff].fatal) before it. > >3. A recvfrom trashes the 8 bytes at the end of a sockaddr_in. This seems > kinda sloppy. The code on line 484 of net/udp.c is where this happens. I'm not sure I know what you are seeing here. Care to elaborate. Alan iiitac@pyr.swan.ac.uk Networking Bod ------------------------------ From: rob@pe1chl.ampr.org (Rob Janssen) Subject: Re: gcc internal compiler error - SIGSE[2~[2SEGV Date: Wed, 9 Mar 1994 09:25:07 GMT Reply-To: pe1chl@rabo.nl In <2lj9b2INNrj1@bowen.ugrad.cs.ubc.ca> z1g192@rick.cs.ubc.ca (Christopher Andrew Smith) writes: >I'm getting an error that I've never seen before when compiling a certain >appliction. What happens is that after I've compiled all the object files >for the application and start linking the application with the library >I made, gcc reports an internal error which I've never encountered before. This problem comes up in the news from time to time. It is generally beleived to be a hardware problem. Please describe your hardware... (CPU type and maker, motherboard, RAM amount and speed) Rob -- ========================================================================= | Rob Janssen | AMPRnet: rob@pe1chl.ampr.org | | e-mail: pe1chl@rabo.nl | AX.25 BBS: PE1CHL@PI8UTR.#UTR.NLD.EU | ========================================================================= ------------------------------ From: rob@pe1chl.ampr.org (Rob Janssen) Subject: Re: Small pre-1.0 problem Date: Wed, 9 Mar 1994 09:31:03 GMT Reply-To: pe1chl@rabo.nl In <2lj62v$2ql@harbinger.cc.monash.edu.au> kevinl@bruce.cs.monash.edu.au (Kevin Lentin) writes: >On Tue, 8 Mar 1994 22:27:36 GMT, Rob Janssen wrote: >> >So this has nothing to do with pre-1.0. >> Indeed. Just use the output of "uname -a" instead of the /proc/version >> file... >Or I could sed out what I don't want, or as I have done, replaced the @ >with an @@ - sed to the rescue. It really doesn't matter one way or the >other. My point was that, as far as I can determine, I saw this the first >time when I installed pre-1.0 and my getty has not changed. But the contents of the version file has sometimes changed... Rob -- ========================================================================= | Rob Janssen | AMPRnet: rob@pe1chl.ampr.org | | e-mail: pe1chl@rabo.nl | AX.25 BBS: PE1CHL@PI8UTR.#UTR.NLD.EU | ========================================================================= ------------------------------ ** FOR YOUR REFERENCE ** The service address, to which questions about the list itself and requests to be added to or deleted from it should be directed, is: Internet: Linux-Development-Request@NEWS-DIGESTS.MIT.EDU You can send mail to the entire list (and comp.os.linux.development) via: Internet: Linux-Development@NEWS-DIGESTS.MIT.EDU Linux may be obtained via one of these FTP sites: nic.funet.fi pub/OS/Linux tsx-11.mit.edu pub/linux sunsite.unc.edu pub/Linux End of Linux-Development Digest ******************************