HDTenEightyP/NetNews huggingface dataset:
From: vikki@e40-008-9.MIT.EDU (Vikki King)
Subject: Kernel rebuild - load error?
Organization: Columbia University Center for Telecommunications Research
X-Newsreader: Tin 1.1 PL4
Date: Sat, 29 Aug 1992 10:58:53 GMT
X-Posted-From: e40-008-9.mit.edu
X-Posted-Through: sol.ctr.columbia.edu

Hi Everyone:

     I am trying to rebuild my kernel to change it so that my 3c503 ethernet
adapter talks out its AUI port instead of the thinnet port.  (Thanks for the
tip Terry :-)!)  I believe that I have altered if_ec.c correctly to accomplish
this.  If I am on the wrong track, feel to let me know.  Anyway, all the
kernel sources seem to compile.  I get to the point:

  load 386 bsd

shortly, I get the error:

  init_main.o: undefined symbol _version refrenced from text segment
  *** error code 1


  stop.

Bummer.  I hunted around trying to see if I could come up with some clever
way to figure this out but, no luck.  I followed the instructions in the file
/sys/conf/ROADMAP exactly, as far as I can tell.  Thanks for any clues :-)!

-John
jackson@a1.mec.mass.edu

Newsgroups: comp.unix.bsd
From: tih@barsoom.nhh.no (Tom Ivar Helbekkmo)
Subject: 386BSD: Better bad144 handling for my WD driver.
Organization: Norwegian School of Economics
Date: Fri, 28 Aug 1992 13:09:49 GMT

For those of you who have picked up my modified wd driver and stuff
from barsoom.nhh.no, here's a little change that should be put in
there (and that's in the version now on barsoom):

In wdstart(), where it scans for bad blocks, the scan through the
bad block list is performed a bit too often -- I didn't consider
the fact that wdstart() is called at interrupt-time for every
sector in a multi-sector transfer.  When this happens, the scan
is not needed, and indeed can cause the driver to be too slow to
handle the transfer properly, thus dropping into one sector per
revolution mode.  This is *slow*!  The test at the top of the loop
should be:

#ifdef TIHBAD144
    /* Check for bad sectors if we have them, and not formatting */
#ifdef  B_FORMAT
    if ((du->dk_flags & DKFL_BADSECT) && !(bp->b_flags & B_FORMAT) &&
        ((du->dk_skip == 0) || (du->dk_flags & DKFL_SINGLE))) {
#else
    if ((du->dk_flags & DKFL_BADSECT) &&
        ((du->dk_skip == 0) || (du->dk_flags & DKFL_SINGLE))) {
#endif

The point is, of course, that if du->dk_skip is nonzero, and we're
not in single sector mode, then we've already checked these blocks.

(I noticed this when I ran Jim Bevier's new bad144 with the -s
option he added.  The scan suddenly slowed to a crawl once it got
past a bad track on one of my disks -- comparing with each of those
26 block numbers for each sector remaining in the transfer just took
too much time...  :-)  Thanks, Jim -- good work!)

-tih
--
Tom Ivar Helbekkmo, NHH, Bergen, Norway.  Telephone: +47-5-959205
Postmaster for domain nhh.no.   Internet mail: tih@barsoom.nhh.no
Newsgroups: comp.unix.bsd
From: volker@sfb256.iam.uni-bonn.de ( Volker A. Brandt )
Subject: Re: Booting 386BSD from second IDE drive?
Organization: Applied Math, University of Bonn, Germany
Date: Tue, 1 Sep 1992 17:29:25 GMT

In article <1992Sep1.154658.18258@motor.physiolmotor.physiol> smg@physiology.oxford.ac.uk (Steve Gough) writes:
>I have installed 386BSD on a whole drive (which was surprisingly easy,
>thanks to the install program).  At the moment to switch between 
>booting DOS or BSD, I swap drive cables, change the CMOS drive parameters
>and reboot---there has to be an easier way!

Yes, we're in the same situation -- we have a 40 MB DOS and a 120 MB 386BSD
drive (both IDE).  We have one of the boot partition selector program, but 
none of the kernels we have tried so far has worked off the second disk.

We can't recompile the system at this point, so we're grateful for any
pointers to kernels or other tools to help alleviate the situation.

Thanks -- Volker

-- 
----------------------------------------------------------------------------
Bitnet:   UNM409@DBNRHRZ1                              Volker A. Brandt
UUCP:     ...!unido!DBNRHRZ1.bitnet!unm409             Angewandte Mathematik
Internet: volker@sfb256.iam.uni-bonn.de                (Bonn, Germany)
From: brian@ucsd.edu (Brian Kantor)
Newsgroups: comp.unix.bsd
Subject: Re: time for comp.unix.bsd.386
Date: 28 Aug 1992 22:38:57 GMT
Organization: The Avant-Garde of the Now, Ltd.
NNTP-Posting-Host: ucsd.edu

In article <6XQIKDA@taronga.com> peter@taronga.com (Peter da Silva) writes:
>I think this hierarchy would be more useful if the name implied "unix like"
>not "posix conforming".

So maybe you want
	comp.os.sue-me-too.bsdi
	comp.os.sue-me-too.bsd43
	comp.os.sue-me-too.bsd44
	comp.os.sue-me-too.386bsd

Me, I like it just fine the way it is.  I don't think the traffic here
warrants a separate group yet.  I'm not sure it ever will; many of the
bugfixes and questions will have application across all the BSD-derived
platforms.
	- Brian
Newsgroups: comp.unix.bsd
From: rcd@raven.eklektix.com (Dick Dunn)
Subject: Re: An overview of 17" monitors
Organization: eklektix - Boulder, Colorado
Date: Tue, 1 Sep 1992 06:13:43 GMT

Amongst a lot of other information, rcpt@urc.tue.nl asks:
>	Will 17" monitors soon become affordable?

My $0.02 (sorry, don't know the exchange rate) is *NO*.  I've been watching
monitor prices over the past 1.5-2 years.  THe inescapable conclusion is
that they are not changing *at*all*.  You'll see a little bit of motion,
but it's really negligible...for example, a Sony 1304 has dropped less than
$100 in price in the last year.

I don't know just what it is that keeps monitor prices so high.  (Conspiracy
theorists, this is your invitation!)  But the prices are entirely inelastic,
and unlike all other equipment in the same market, improvement has been
minimal-to-nonexistent.
-- 
Dick Dunn    rcd@raven.eklektix.com   -or-   raven!rcd    Boulder, Colorado
				Cats!
From: spedpr@thor.cf.ac.uk (Paul Richards)
Newsgroups: comp.unix.bsd
Subject: Trident X server
Date: 2 Sep 92 22:56:08 GMT
Organization: University of Wales College at Cardiff
X-Mailer: Cardiff Computing Maths PP Mail Open News Gateway

Is there anyone with a Trident X386 server?

It doesn't really matter if it has a few glitches because my main use of
the server will be across the net to my sun. Anything that will pop up
an xterm will suit me!
-- 
  Paul Richards at Cardiff university, UK.

  spedpr@uk.ac.cf.thor	Internet: spedpr%thor.cf.ac.uk@nsfnet-relay.ac.uk
  UUCP:     spedpr@cf-thor.UUCP or ...!uunet!mcsun!uknet!cf!thor!spedpr
+++
From: joergens@snorre.informatik.uni-dortmund.de (Ulrich Joergens (PG211))
Newsgroups: comp.unix.bsd
Subject: X386 & Keyboard
Date: 1 Sep 1992 15:51:09 GMT
Organization: CS Department, Dortmund University, Germany
Distribution: world
NNTP-Posting-Host: snorre

I have the following problem:

starting xdm from /etc/rc (as last entry) my keyboard is ignored.
From: gab10@griffincd.amdahl.com (Gary A Browning)
Newsgroups: comp.unix.bsd
Subject: Re: X386 and Diamond Stealth: not solution
Date: 26 Aug 92 03:17:13 GMT
Distribution: comp.unix.bsd
Organization: Amdahl Corporation, Sunnyvale CA

In article <-bannhr.hasty@netcom.com>, hasty@netcom.com (Amancio Hasty
Jr) writes:
> 
> Hello,
> 
> This is a quick update on Diamond Stealth (S3 based svga).
> 
> According to Geoff Orr, from Diamond, they are not going to publicly 
> release information on how to set their clocks. All new Diamond cards
> not just the S3 based cards will use this method. 

I have a hard time believing that Diamond marketing believes this policy is in
the best interest of the company.  How is this going to save/make the company
money?  Does Geoff really represent Diamond?  Which area does Geoff work for?

I saved the Diamond BBS number from some other posting; 1-408-730-1100.  Maybe
someone with a modem can verify this policy?  or at least inform the rest
of the Diamond user community of this decision.
-- 
Gary Browning - another unhappy Diamond Video Card owner.
From: adrian@ibmpcug.co.uk (Adrian Hall)
Newsgroups: comp.unix.bsd
Subject: Re: Kernel rebuild - load error?
Date: 29 Aug 92 11:32:23 GMT
Organization: The IBM PC User Group, UK.

In the (Unofficial) Bug list, there is this to say :-

	Problem:	As distributed, you cannot make a kernel
			because the Makefile doesn't include
			vers.c/vers.o

	Solution:	Chris Demetriou has a patch on agate (in
			unofficial/Makefile.cgd I think) that
			fixes the problem.

I suggest looking through the 386BSD FAQ and Bug List - there is
a lot of stuff there that has helped me. ( I got my copy from
the 386BSD bot on IRC - but I guess they are also elsewhere).

Adrian

-- 
--------------------------------------------------------------------------
Adrian Hall					Connect Systems Manager
adrian@ibmpcug.co.uk				The IBM PC User Group
Tel: +44 81 863 1191				Harrow, London, UK
From: dmp3592@galileo.rtn.ca.boeing.com (Dean M. Phillips)
Newsgroups: comp.unix.bsd
Subject: Re: Booting 386BSD from second IDE drive?
Summary: PCs do not boot from second drive.
Date: 2 Sep 92 14:09:26 GMT
Organization: Boeing Commercial Airplane Group, Seattle

In general, a PC clone has no way to boot from a second drive.  The BIOS
ROM does not support this.  The MSDOS boot code, I think, does not support
this and I know that the wd*.c boot code in 386bsd does not support this.

I have a system with a 124Mb drive 0 and a 42Mb drive 1.  I worked around
this problem by creating a 31.9Mb DOS partition and a 92Mb 386bsd partion
on drive 0.  Drive 1 is 100% 386bsd.  I put the man pages and emacs and
some other less often used stuff on the 42Mb drive because it is slower.
This partitioning is less convient than having it all in one piece but it
does allow me to switch back and forth without minor surgery.
-- 
----------------------------------------------------------------------
#include <standard_disclaimer.h>
Dean M. Phillips                                        (206) 393-9333
Boeing Commercial Airplane Group            dmp3592@galileo.boeing.com
Newsgroups: comp.unix.bsd
From: nbladt@autelca.ascom.ch (Norbert Bladt)
Subject: Re: Is runnning BSD feasible??
Organization: Ascom Autelca AG, Guemligen, Switzerland
Date: Thu, 27 Aug 1992 08:47:04 GMT

kilroy@mik.uky.edu (Paul S. Kilroy) writes:

>Hi all,

>	Sorry, I dont know if this is a FAQ so please bear with me...
>   I was wondering if running BSD on a 486 with 8 meg of ram on a
>   pc in my home is feasible(ie. not too many bugs). I have heard
>   mixed reviews about the bugginess of BSD. I would be doing simple
>   things such as running X-windows, writting small programs for 
Now is the time for X to become simple :-) :-)
Sorry, I couldn't resist that one.

But serious:
I installed the base system on a 486/25 Mhz with 16MB of RAM (will
increase swap space after installing the kernel source), the
1542B controller in about two hours (from floppy). That did include
the copying of the 10 Floppies to harddisk on another PC (via
Ethernet) and then to the floppies. This took about half an hour.
Before that, I spent one hour to figure out that the WD ethernet
adaptor which is in this system running 386BSD had a hardware
problem (checksum error in address ROM) but was detected by 386BSD.
So, all in all the real installation took about one hour and it
worked after the first try. Even with a 25 MB MS-DOS partition.

Norbert.
-- 
Norbert Bladt, Ascom Autelca AG, Worbstr. 201, CH-3073 Guemligen, Switzerland
Phone: +41 31 999 65 52			FAX: +41 31 999 65 44
Mail: nbladt@autelca.ascom.ch   UUCP: ..!uunet!mcsun!chsun!hslrswi!aut!nbladt
Newsgroups: comp.unix.bsd
From: a0045@rrz.uni-koeln.de (Jochen Roderburg)
Subject: 386BSD FP problems, or: why is 0.0 == -1.0 ??
Organization: Regional Computing Center, University of Cologne, F. R. Germany
Distribution: comp
Date: 2 Sep 92 12:05:30

The C system on 386BSD seems to have some strange problems with
floating-point constants. 

The following test program justs prints out a few constants:

main () { 
printf ("0.  %+f\n", 0. ); 
printf ("0.0 %+f\n", 0.0); 
printf ("0.1 %+f\n", 0.1); 
printf ("0.5 %+f\n", 0.5); 
printf ("0.6 %+f\n", 0.6); 
printf ("1.0 %+f\n", 1.0); 
printf ("1.1 %+f\n", 1.1); 
printf ("1.5 %+f\n", 1.5); 
printf ("1.6 %+f\n", 1.6); 
}

And these are the suprising results:

0.  +0.000000
0.0 -1.000000
0.1 +0.000000
0.5 +0.000000
0.6 +1.000000
1.0 +1.000000
1.1 +1.000000
1.5 +2.000000
1.6 +2.000000

Especially entertaining is the wonderful transformation from 0.0 to -1.0.
You may understand that a small utility which uses a few of these constants 
brought not very useful results. 

The errors seem to happen already in the compiler, not during the printout.
When you use the constants in expressions you get results that fit to the
printout, for example  2+0.0 -> 1.0.

I have observed this on PCs without mathematical coprocessor, if this is of
any importance.

Has anybody a clue what is going on here ?

Jochen Roderburg
Regional Computing Center
University of Cologne
Robert-Koch-Str. 10                    Tel.:   +49-221/470-4564
D-5000 Koeln 41                        E-Mail: Ro @ RRZ.Uni-Koeln.DE
Germany
From: kent@sparky.imd.sterling.com (Kent Landfield)
Subject: Re: lockd on 386BSD
Organization: Sterling Software
Date: Tue, 25 Aug 1992 21:44:37 GMT
X-Md4-Signature: 7fa61a2eec82b99dfd8e79d02889d7e7

In article <BtHnEo.GpE@chinet.chi.il.us> randy@chinet.chi.il.us (Randy Suess) writes:
>In article <1992Aug23.205117.5204@fcom.cc.utah.edu> terry@cs.weber.edu (A Wizard of Earth C) writes:
>>2)	The append failure is not a result of NFS.  It's a result of a rather
>>	loose interpretation of the "a" and "a+" modes in POSIX 1003.1.  You
>>	would be better off fixing the shell, or you're bound to repeat the
>>	performance later with some other box.
>
>	Problem is, it is not just the shell.  I use the archive program,
>	rkive to archive the sources groups.  I used to have the archives
>	directory mounted on my main system.  Now that the archives file
>	system has grown to over 200 megs (os2 is a prolific os!)
>	I mounted it on the BSD system.  Since then, nothing but garbage.
>	rkive appends to log, index and a few other house keeping files.
>	All these files are complete garbage since moving to BSD.
>	I temporarily moved the archive to my Novell 3.11/NFS system, and
>	things are fine.

The problem is not rkive's.  Yeah, right.. You knew I'd say that... :-) But
it isn't.  Archives have been maintained by rkive via NFS in quite a few 
places, on different platforms and have been for years now.  

>> The particular ambiguity I am referring to was discussed here before;
>> in particular, if you open a file in append mode, the file pointer is
>> set to the end of the file.  If you seek to a different offset prior
>> to the EOF point, the seek places the pointer at EOF, not at the requested
>> location.  In combination with the create flag, this can cause full
>> truncation.

Rkive just opens the file a+ (why the '+ is there, I do not know but that is 
another question) and does not move the file pointer. Just an open and a 
fprintf().

This sounds like a real NFS daemon bug...

PS. I'm removing the '+' on the opens since its not needed.  Next release...

			-Kent+
---
Kent Landfield                   INTERNET: kent@IMD.Sterling.COM
Sterling Software, IMD           UUCP:     uunet!sparky!kent
Phone:    (402) 291-8300         FAX:      (402) 291-4362
Please send comp.sources.misc-related mail to kent@uunet.uu.net.
Newsgroups: comp.unix.bsd
From: peter@taronga.com (Peter da Silva)
Subject: Re: time for comp.unix.bsd.386
Organization: Taronga Park BBS
Date: Fri, 28 Aug 1992 12:52:48 GMT

In article <1992Aug27.091607.12110@resonex.com> michael@resonex.com (Michael Bryan) writes:
>Personally, I rather like Peter's recent suggestion of comp.os.posix.*

Except that "posix" itself is problematical. For example, there are real
unix-like systems that aren't posix compliant (386BSD, for example) and
there are completely un-unixy POSIX environments (Open VMS). From what I
can tell, most normal UNIX programs will crash and burn on Open VMS (for
example, anything that expects to access files with specific names)...

I think this hierarchy would be more useful if the name implied "unix like"
not "posix conforming".
-- 
                                                                `-_-'
                         Have you hugged your wolf today?        'U`

Peter da Silva, Taronga Park BBS, Houston, TX  +1 713 568 0480/1032
Newsgroups: comp.unix.bsd
From: peter@taronga.com (Peter da Silva)
Subject: Re: time for comp.unix.bsd.386
Organization: Taronga Park BBS
Date: Thu, 27 Aug 1992 13:03:59 GMT

In article <1992Aug27.093740.29039@uniwa.uwa.edu.au> craig@ec.uwa.oz.au (Craig Richmond - division) writes:
>peter@taronga.com (Peter da Silva) writes:
>>FWIW, if we're going to have a bunch of comp.os.unix-alike groups, then
>>this should be comp.os.386bsd. I think it would be better to put the
>>unix-alikes together in a common hierarchy, but for political reasons
>>we shouldn't single out 386bsd as a special case.

>comp.os.UNIX.386bsd

>*craig screams loudly*

Oh, we're at the screaming horror from the sewers of hell stage already,
and the RFD hasn't even started?

I was thinking more of comp.posix.*.

Or, to cut down on the buzz-phrases, comp.os.portable.*.

Can't say open, because DEC will claim that VMS is an open system now...
-- 
                                                                `-_-'
                         Have you hugged your wolf today?        'U`

Peter da Silva, Taronga Park BBS, Houston, TX  +1 713 568 0480/1032
Newsgroups: comp.unix.bsd
From: liu@cs.sfu.ca (Lixin Liu)
Subject: Gnuplot3.2 under 386BSD --- GCC bug ?
Organization: CSS, Simon Fraser University, Burnaby, B.C., Canada
Date: Tue, 1 Sep 1992 21:29:03 GMT

Hi everyone, 

   I tried to compile Gnuplot3.2 on a 486 machine running 386BSD 0.1 and
got the following error:

cc  -g  -DREADLINE -DNOCWDRC -c command.c -DHELPFILE=\"/usr/local/lib/gnuplot.gih\"
cc: Program cc1 got fatal signal 6.
*** Error code 1

Stop.

I can sent you the core file if you need.

Thanks.

Lixin
-- 
    mail:  Lixin Liu,   Department of Mathematics and Statistics,
           Simon Fraser University, Burnaby, B.C., CANADA  V5A 1S6
  e-mail:  liu@cs.sfu.ca   OR   liu@sfu.ca
   phone:  (604) 291-3422  (office),  (604) 294-6582 (home)
From: ajv@xhost92.csd.mot.com
Newsgroups: comp.unix.bsd
Subject: Re: Hardware Configuration to run 386BSD
Date: 1 Sep 92 20:39:26 GMT

ghe@ruhets.rutgers.edu (Guangliang He) writes:

>I am interested to know what is needed to run a 386BSD system
>comfortablly. A 33 MHz 486 system? How much of RAM? 8 Meg enough? 16?
>Harddisk? How much to hold all bsd (including source and manual)? What
>if including latest version of X-window systems. Of course, I would
>like to have some space left to do programming.

Leaving out X, you can run quite comfortably on 4 Mb RAM, 25 Mhz 386,
and 100 Mb of disk.  I left off the source to GNU C and a couple other
"biggies", but otherwise was able to install both source and binary,
and build kernels and commands.

Since then I've added a 1.2 Gb SCSI disk.  The GNU C source is
back on-line! :-)

						Andy Valencia
Newsgroups: comp.unix.bsd
From: veit@du9ds3.uni-duisburg.de (Holger Veit)
Subject: Re: What is included in the ectdist directoy?
Date:  2 Sep 92 09:47:04 GMT
Reply-To: veit@du9ds3.uni-duisburg.de
Organization: Uni-Duisburg FB9 Datenverarbeitung

In <colin.715403815@marsh> colin@marsh.cs.curtin.edu.au (Colin Manning) writes:

>kilroy@mik.uky.edu (Paul S. Kilroy) writes:

>>Hi, 
>>  does anyone have a list of the files in the ectdist distribution?

>You could read the MANIFEST.ETC01 (not sure if thats exact) on agate,  but it
>is the manifest file for the srcdist.  Could someone fix this please?

>>thanks
>>paul
>>(kilroy@mik.uky.edu)
>>--
>>                       -Paul   (kilroy@mik.uky.edu)
>--
>Colin [colin@cs.curtin.edu.au]

>"Knowledge is not knowing all the answers, but knowing where to find them."
>                                                                  -anon.

Look into the files CONTENTS.CPIO.Z in the bindist/srcdist/etcdist directories
at ftp.uni-duisburg.de (134.91.4.132) (under the /pub/unix/386bsd-0.1 tree).
These are the CPIO tables of contents of the distribution sets.
The MANIFEST.ETC01 anywhere in the kit is indeed the source list.

Holger

-- 
|  |   / Dr. Holger Veit         | INTERNET: veit@du9ds3.uni-duisburg.de
|__|  /  University of Duisburg  | BITNET: veit%du9ds3.uni-duisburg.de@UNIDO
|  | /   Dept. of Electr. Eng.   | "No, my programs are not BUGGY, these are
|  |/    Inst. f. Dataprocessing |          just unexpected FEATURES"
Newsgroups: comp.unix.bsd
From: sangster@news.ans.net (Paul Sangster)
Subject: BSD port to RS/6000?
Date: Fri, 28 Aug 1992 15:46:38 GMT
Organization: Advanced Network & Services - Elmsford, VA
Followup-To: sangster@ans.net


Greetings,

Has anyone out there in netland attempted porting some recent release
of BSD to the IBM RS/6000?  If anyone know anything about someone who
has done or is doing this effort, please drop me some e-mail.

Paul
-- 
_______________________________________________________________________
Paul Sangster                        Snail mail: 1875 Campus Commons Dr. 
Advanced Network & Services                      Suite 220
Information & Applications Services Group        Reston, Va 22091
From: cagney@cs.adelaide.edu.au (Andrew Cagney - aka Noid)
Newsgroups: comp.unix.bsd
Subject: How to rebuild x386 under 386bsd?
Keywords: 386BSD x386
Date: 2 Sep 92 14:06:17 GMT
Reply-To: cagney@cs.adelaide.edu.au (Andrew Cagney - aka Noid)
Followup-To: comp.unix.bsd
Organization: Comp Sci, Uni of Adelaide, Australia

I'm trying to rebuild the x386 server and am having problems with the
system include files being missing (eg termio.h, there is a termios.h).
I can't find the missing include files in the basic 386BSD distribution.

Are there any problems in re-building the x386 server under 386BSD or
have I simply missed something obvious?

Any help would be appreciated

					Andrew Cagney
					cagney@cs.adelaide.edu.au
From: rexw@hardy.u.washington.edu (Rex Warren)
Newsgroups: comp.unix.bsd
Subject: HD won't boot
Date: 3 Sep 92 23:34:39 GMT
Article-I.D.: u.1992Sep3.233439.7514
Reply-To: rexw@u.washington.edu
Distribution: usa
Organization: University of Washington, Seattle


Hi,  I'm trying to boot bsd on a gateway with a 150 M ESDI hard drive
and I get the bad sector error.  How do I fix the bad sector table?
I tried bad144 with many different forms of the incantation but it
keeps telling me it can't write to the bad sector table.  Do I need
to make this its own partition?

Sorry if this has been asked before.  I firsted installed it on a notebook
and didn't have this problem.  Please mail or post an answer.

Thanks in advance
Rex Warren
Newsgroups: comp.unix.bsd
From: hlu@poly2.eecs.wsu.edu (H.J. Lu)
Subject: Re: [386bsd] Virtual memory exhausted. Do I need more swap?
Organization: Washington State University
Date: Wed, 2 Sep 92 00:14:59 GMT

In article <david.714981284@mlb.geomechanics.csiro.au>, david@mlb.geomechanics.csiro.au (David Le Blanc) writes:
|> When compiling some programs with GCC, I get the message 'virtual memory
|> exhausted'. I have 40Meg virtual memory, so I am sure that is not the problem.
|> 
|> Is there a setting with GCC which I should raise or what??
|> 
|> Thanks.
|> 
|> --
|> David Le Blanc                         :
|> Email: david@mlb.geomechanics.csiro.au : `Sort of a cross between a Jaguar
|> CSIRO Division of Geomechanics,	       :  and a freight train.' the Alien
|> P.O. Box 54 Mt Waverley 3149	       : in Alien^3.


That is a known problem in gcc. If you have a very big initialized
array, you probably will get this. RMS has asked for a volunteer to fix
this.

H.J.