537 lines
21 KiB
Plaintext
537 lines
21 KiB
Plaintext
From: Digestifier <Linux-Development-Request@senator-bedfellow.mit.edu>
|
|
To: Linux-Development@senator-bedfellow.mit.edu
|
|
Reply-To: Linux-Development@senator-bedfellow.mit.edu
|
|
Date: Sun, 25 Sep 94 17:13:11 EDT
|
|
Subject: Linux-Development Digest #226
|
|
|
|
Linux-Development Digest #226, Volume #2 Sun, 25 Sep 94 17:13:11 EDT
|
|
|
|
Contents:
|
|
Re: [STATUS] Linus Floppy Driver Development (H. Peter Anvin)
|
|
Re: polled ports ("Theodore Ts'o")
|
|
ftape 1.13b overrun (A.Couture@agora.stm.it)
|
|
Re: 1+ Gig SCSI Drives (H. Peter Anvin)
|
|
Re: elf benchmarks (getting closer) (H.J. Lu)
|
|
Re: AX25 & KISS Amateur Radio Protocols in Linux?? (Mark A. Horton KA4YBR)
|
|
Re: memory leakage in 1.1.51 ? (FIX) (Guenther Thomsen)
|
|
Re: Missing stdarg.h and (sort of) varargs.h (H.J. Lu)
|
|
more floppy problems with 1.1.51 (Steve DuChene)
|
|
Warnings with libc 4.5.26. (Michael H. Price II)
|
|
Re: A badly missed feature in gcc (H. Peter Anvin)
|
|
|
|
----------------------------------------------------------------------------
|
|
|
|
From: hpa@hook.eecs.nwu.edu (H. Peter Anvin)
|
|
Subject: Re: [STATUS] Linus Floppy Driver Development
|
|
Date: Sun, 25 Sep 1994 16:54:26 GMT
|
|
|
|
In article <1994Sep25.102533.254@acad.ursinus.edu>,
|
|
Steve Kneizys <STEVO@acad.ursinus.edu> wrote:
|
|
>
|
|
>: What if they did something like on the sgi's, where you can specify
|
|
>: a mount point for dos disks, and run a daemon that will mount the floppy
|
|
>: automagically (at least, for a dos disk). Pretty neat though. Perhaps
|
|
>: if we had something like that for msdos disks only, all others needing
|
|
>: to be mounted manually (therefore, by root)?
|
|
>
|
|
>Sounds like a neat idea...if root starts such a daemon, then I like it!
|
|
>Having msdos automount, but not minix, would solve much of the security
|
|
>problem that I would run into.
|
|
>
|
|
|
|
I personally still prefer the explicit mount command (using the "user"
|
|
option in /etc/fstab) for one reason: that way the OS knows who owns
|
|
the disk. If a disk is inserted and something like SGI's mediad is
|
|
used, there is nothing that can be done except making it world
|
|
read/writeable. SGI uses it for CD-ROMs, which is much less of a
|
|
problem. It means someone telnetted in can read and wipe your data if
|
|
you put it in the disk.
|
|
|
|
The final problem is that the hardware on PCs doesn't keep you from
|
|
ejecting the disk, and if people can insert a disk to have it
|
|
mounted, I can guarantee they will not remember to use an explicit
|
|
umount. The only way it can be solved is in hardware (with a
|
|
motorized eject mechanism and an eject button that can be overridden
|
|
by the OS. Ideally, the eject button should trap the OS, which could
|
|
umount the disk and then eject it).
|
|
|
|
/hpa
|
|
|
|
--
|
|
This message was sent from a system running Linux, the freeware UNIX
|
|
clone. Get yours from tsx-11.mit.edu or sunsite.unc.edu.
|
|
|
|
------------------------------
|
|
|
|
From: "Theodore Ts'o" <tytso@MIT.EDU>
|
|
Subject: Re: polled ports
|
|
Date: 25 Sep 1994 14:49:52 -0400
|
|
Reply-To: tytso@MIT.EDU
|
|
|
|
Date: Sat, 24 Sep 94 20:40:53 -0400
|
|
From: Theodore Ts'o <tytso@MIT.EDU>
|
|
|
|
Sorry for the late followup, but I only had a chance to look at this
|
|
now... Actually FIFO's are disabled a speeds below 2400 --- the only
|
|
thing that happens is that the FCR_TRIGGER is set at 1, so that an
|
|
interrupt is signalled after one character is in the FIFO. Of course,
|
|
this makes no difference if you are polling. So the FIFO's are enabled
|
|
even at speeds below 2400 bps, and so getting a 16550A chip if you are
|
|
doing polled operations is highly recommended.
|
|
|
|
Oops... typo. The second line should read, "Actually, FIFO's *aren't*
|
|
disabled at speeds below 2400"....
|
|
|
|
Hopefully the general thrust of the message was still clear, but just in
|
|
case it wasn't, I wanted to clear things up.
|
|
|
|
- Ted
|
|
|
|
------------------------------
|
|
|
|
From: A.Couture@agora.stm.it
|
|
Subject: ftape 1.13b overrun
|
|
Date: 25 Sep 1994 14:53:17 -0400
|
|
Reply-To: A.Couture@agora.stm.it
|
|
|
|
|
|
Date: Sun, 25 Sep 1994 17:03:58 +0000
|
|
From: Andre Couture <andrec@cyborg.cic>
|
|
Sender: Andre Couture <andrec@cyborg.cic>
|
|
Reply-To: Andre Couture <andrec@cyborg.cic>
|
|
Subject: ftape 1.13b overrun
|
|
To: Bas Laarhoven <bas@vimec.nl>
|
|
cc: "comp.os.linux.help" <linux-help@news-digests.mit.edu>,
|
|
"comp.os.linux.development" <linux-development@news-digests.mit.edu>
|
|
Message-ID: <Pine.3.89.9409251602.A3133-0100000@cyborg>
|
|
MIME-Version: 1.0
|
|
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
|
|
|
|
|
|
I have installed the ftape1.13b,
|
|
compiled ok, installed ok, ...
|
|
|
|
The problems are when I write to tapes, I get a lots of write errors and
|
|
also a lots of overruns.
|
|
|
|
The tape has been formatted under DOS or Windows (CBWLITE) ? not too sure
|
|
as my brother did it!
|
|
|
|
Is there any formatting tools comming up for Linux?
|
|
|
|
|
|
Does anybody experiencing the same problems?
|
|
|
|
My system is:
|
|
486dx50 EISA
|
|
20MB RAM
|
|
Adaptec 1742A (EISA-Enhanced mode)
|
|
Colorado 250MB attached to the floppy.
|
|
Quantum LPS525 HDD
|
|
|
|
OS Kernel 1.1.51
|
|
|
|
Here is some info from the messages file:
|
|
|
|
[005] fdc-io.c (fdc_config) - FC-10 controller not found.
|
|
[006] fdc-io.c (fdc_probe) - Type 82077 or compatible FDC found.
|
|
[007] fdc-io.c (fdc_fifo_enable) - fifo already enabled, thresshold 0.
|
|
[008] fdc-io.c (fdc_init) - FDC fifo successfully enabled.
|
|
[009] ftape-io.c (_ftape_open) - drive wakeup method: Colorado.
|
|
[010] ftape-io.c (ftape_report_raw_drive_status) - warning: error status
|
|
|
|
set!
|
|
...
|
|
[023] ftape-io.c (ftape_report_error) - errorcode: 26.
|
|
[024] ftape-io.c (ftape_report_error) - Non-Fatal ERROR:.
|
|
[025] ftape-io.c (ftape_report_error) - Power On Reset Occurred ....
|
|
[026] ftape-io.c (ftape_report_error) - ... caused by unknown command 0.
|
|
[027] ftape-io.c (_ftape_open) - error code : 26.
|
|
[028] ftape-io.c (_ftape_open) - error command: 0.
|
|
[029] ftape-io.c (_ftape_open) - status: new cartridge.
|
|
[030] ftape-io.c (ftape_report_vendor_id) - got 16 bit id: 0047.
|
|
[031] ftape-io.c (ftape_report_vendor_id) - CMS rom version: 87.
|
|
[032] ftape-io.c (ftape_report_vendor_id) - CMS signature: a5.
|
|
[033] ftape-io.c (ftape_report_vendor_id) - CMS status: 4.
|
|
[034] ftape-io.c (_ftape_open) - ftape drive type is: Colorado
|
|
DJ-10/DJ-20.
|
|
[035] ftape-io.c (ftape_set_data_rate) - Data rates set to 1 Mbps.
|
|
[036] ftape-io.c (ftape_get_tape_parameters) - segments_per_cylinder 4.
|
|
[037] ftape-io.c (ftape_get_tape_parameters) - segments_per_track 150.
|
|
[038] ftape-io.c (ftape_get_tape_parameters) - segments_per_head 600.
|
|
[039] ftape-io.c (ftape_get_tape_parameters) - sectors_per_segment 32.
|
|
[040] ftape-io.c (ftape_get_tape_parameters) - tracks_per_tape 28.
|
|
[041] fdc-io.c (fdc_init) - FDC fifo successfully enabled.
|
|
[042] ftape-read.c (read_header_segment) - segments-per-track: 150.
|
|
[043] ftape-read.c (read_header_segment) - tracks-per-cartridge: 28.
|
|
[044] ftape-read.c (read_header_segment) - max-floppy-side: 6.
|
|
[045] ftape-read.c (read_header_segment) - max-floppy-track: 149.
|
|
[046] ftape-read.c (read_header_segment) - max-floppy-sector: 128.
|
|
[047] ftape-read.c (read_header_segment) - first data segment: 2.
|
|
[048] ftape-read.c (read_header_segment) - `last' segment is 4199, 29
|
|
Kb.
|
|
[049] ftape-read.c (read_header_segment) - 121652 Kb usable on this
|
|
tape.
|
|
[050] ftape-eof.c (extract_file_marks) - number of file marks: 10.
|
|
[051] ftape-eof.c (extract_file_marks) - eof mark in segment 17, sector
|
|
10.
|
|
[052] ftape-eof.c (extract_file_marks) - eof mark in segment 18, sector
|
|
1.
|
|
[053] ftape-eof.c (extract_file_marks) - eof mark in segment 20, sector
|
|
17.
|
|
[054] ftape-eof.c (extract_file_marks) - eof mark in segment 21, sector
|
|
1.
|
|
[055] ftape-eof.c (extract_file_marks) - eof mark in segment 500,
|
|
sector 6.
|
|
[056] ftape-eof.c (extract_file_marks) - eof mark in segment 501,
|
|
sector 1.
|
|
[057] ftape-eof.c (extract_file_marks) - eof mark in segment 554,
|
|
sector 7.
|
|
[058] ftape-eof.c (extract_file_marks) - eof mark in segment 555,
|
|
sector 1.
|
|
[059] ftape-eof.c (extract_file_marks) - eof mark in segment 641,
|
|
sector 9.
|
|
[060] ftape-eof.c (extract_file_marks) - eof mark in segment 642,
|
|
sector 1.
|
|
[061] fdc-io.c (fdc_init) - FDC fifo successfully enabled.
|
|
[062] fdc-io.c (fdc_init) - FDC fifo successfully enabled.
|
|
[063] fdc-io.c (fdc_init) - FDC fifo successfully enabled.
|
|
[064] ftape-write.c (_write_segment) - empty segment, nothing written.
|
|
[065] ftape-write.c (_write_segment) - empty segment, nothing written.
|
|
[066] fdc-isr.c (fdc_isr) - single overrun error.
|
|
[067] fdc-isr.c (determine_progress) - Unexpected error at sector offset
|
|
0.
|
|
[068] ftape-rw.c (ftape_smart_stop) - tape stopped passing segment: 12.
|
|
[069] ftape-write.c (_write_segment) - write error, retrying (0).
|
|
[070] fdc-isr.c (fdc_isr) - single overrun error.
|
|
[071] fdc-isr.c (determine_progress) - Error at sector offset 2.
|
|
[072] fdc-isr.c (retry_sector) - request skipping of 3 sectors.
|
|
[073] ftape-rw.c (ftape_smart_stop) - tape stopped passing segment: 23.
|
|
[074] ftape-write.c (_write_segment) - write error, retrying (0).
|
|
[075] ftape-write.c (copy_and_gen_ecc) - bad sectors in map: 1.
|
|
[076] ftape-rw.c (setup_segment) - segment: 30, bad sector map:
|
|
000000
|
|
[077] fdc-isr.c (fdc_isr) - single overrun error.
|
|
[078] fdc-isr.c (determine_progress) - Error at sector offset 13.
|
|
[079] fdc-isr.c (retry_sector) - request skipping of 15 sectors.
|
|
[080] ftape-rw.c (ftape_smart_stop) - tape stopped passing segment: 31.
|
|
[081] ftape-rw.c (setup_segment) - segment: 30, bad sector map:
|
|
00000040.
|
|
...
|
|
[244] ftape-io.c (_ftape_close) - error: unable to update header segments.
|
|
[245] ftape-io.c (_ftape_close) - == Non-fatal errors this run: ==.
|
|
[246] ftape-io.c (_ftape_close) - fdc isr statistics:.
|
|
[247] ftape-io.c (_ftape_close) - id_am_errors : 4.
|
|
[248] ftape-io.c (_ftape_close) - id_crc_errors : 0.
|
|
[249] ftape-io.c (_ftape_close) - data_am_errors : 0.
|
|
[250] ftape-io.c (_ftape_close) - data_crc_errors : 0.
|
|
[251] ftape-io.c (_ftape_close) - overrun_errors : 78.
|
|
[252] ftape-io.c (_ftape_close) - no_data_errors : 9.
|
|
[253] ftape-io.c (_ftape_close) - retries : 91.
|
|
[254] ftape-io.c (_ftape_close) - repositions : 90.
|
|
[255] ftape-io.c (_ftape_close) - last segment : 2251.
|
|
[000] kernel-interface.c (ftape_close) - _ftape_close failed.
|
|
|
|
|
|
=====
|
|
Andre Couture,
|
|
A.Couture@Agora.stm.it (prefered)
|
|
_/_/_/_/ _/_/_/_/ _/_/_/_/ Centre Informatique Couture
|
|
_/ _/ _/ 938934 Ontario Inc. Phone:
|
|
+1-613-762-0262
|
|
_/ _/ _/ 155 Queen St. FAX:
|
|
+1-819-775-9697
|
|
_/ _/ _/ Suite 900 Roma:
|
|
+39/6-5125-745
|
|
_/ _/ _/ Ottawa, Ontario Delphi:
|
|
CoutureA
|
|
_/_/_/_/. _/_/_/_/. _/_/_/_/.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
@receiver file
|
|
|
|
|
|
------------------------------
|
|
|
|
From: hpa@ahab.eecs.nwu.edu (H. Peter Anvin)
|
|
Subject: Re: 1+ Gig SCSI Drives
|
|
Reply-To: hpa@nwu.edu (H. Peter Anvin)
|
|
Date: Sun, 25 Sep 1994 17:45:32 GMT
|
|
|
|
Followup to: <CwLEFx.9t3@ix.de>
|
|
By author: hm@ix.de
|
|
In newsgroup: comp.os.linux.development
|
|
>
|
|
> > I once read a rumor about a new filesystem standard. I believe that
|
|
> > ALL unices are limited to 2G partition sizes due to the 32 bit file
|
|
> > pointer accepted by the standard OS entry points. Perhaps there is a
|
|
> > movement afoot to go to 64 bit pointers as did Microsoft with Windows
|
|
> > NT.
|
|
>
|
|
> Linus introduced 64 bit pointers recently.
|
|
>
|
|
|
|
No. They are, however, limited to 2 Gb *files* unless long is more
|
|
than 32 bits.
|
|
|
|
--
|
|
INTERNET: hpa@nwu.edu --- Allah'u'abha ---
|
|
IBM MAIL: I0050052 at IBMMAIL HAM RADIO: N9ITP or SM4TKN
|
|
FIDONET: 1:115/511 or 1:115/512 STORMNET: 181:294/1 or 181:294/101
|
|
#include <sig/virus.h>
|
|
|
|
------------------------------
|
|
|
|
From: hjl@nynexst.com (H.J. Lu)
|
|
Subject: Re: elf benchmarks (getting closer)
|
|
Date: 25 Sep 1994 12:43:34 GMT
|
|
|
|
H.J. Lu (hjl@nynexst.com) wrote:
|
|
: John Richardson (jrichard@cs.uml.edu) wrote:
|
|
: : As a quick followup to my very unscientific benchmark:
|
|
: :
|
|
: : The with the latest gcc (23-Sept) and the 4.6.11 elf libraries,
|
|
: : elf narrows the time gap to about a 3.5% difference using the qsort() test.
|
|
|
|
: The ELF/PIC library may not be in core all the time. The ELF binary
|
|
: may have to load it everytime it runs. Please re-compile your login
|
|
: shell with ELF and then re-run the "benchmark." If that is the case,
|
|
: ELF may be faster :-).
|
|
|
|
Here are my 100000 qsort results:
|
|
|
|
# time aout; time aout; time aout; time elf; time elf; time elf
|
|
117.76user 0.05system 1:58.87elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k
|
|
0inputs+0outputs (0major+0minor)pagefaults 0swaps
|
|
95.44user 0.02system 1:35.74elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k
|
|
0inputs+0outputs (0major+0minor)pagefaults 0swaps
|
|
124.47user 0.02system 2:05.69elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k
|
|
0inputs+0outputs (0major+0minor)pagefaults 0swaps
|
|
98.95user 0.06system 1:39.52elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k
|
|
0inputs+0outputs (0major+0minor)pagefaults 0swaps
|
|
85.78user 0.08system 1:26.96elapsed 98%CPU (0avgtext+0avgdata 0maxresident)k
|
|
0inputs+0outputs (0major+0minor)pagefaults 0swaps
|
|
105.15user 0.15system 1:46.06elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k
|
|
0inputs+0outputs (0major+0minor)pagefaults 0swaps
|
|
|
|
|
|
No, that is not a typo. ELF may be faster than a.out. But don't take
|
|
the result as is. 1000000 iterations are too small. The "benchmark"
|
|
varies a lot for both a.out and ELF. We need a better benchmark for
|
|
the ELF/PIC library. Also an ELF login shell makes a big diference.
|
|
|
|
BTW, my login is an ELF zsh and my machine is 486DX2/66 with 16 MB RAM.
|
|
|
|
--
|
|
First I thought he was on hunger strike. Later I was told he was
|
|
praticing YanXin QiGong.
|
|
|
|
------------------------------
|
|
|
|
From: mah@ka4ybr.com (Mark A. Horton KA4YBR)
|
|
Subject: Re: AX25 & KISS Amateur Radio Protocols in Linux??
|
|
Date: Sun, 25 Sep 1994 14:55:25 GMT
|
|
|
|
Grant Edwards (grante@reddwarf.rosemount.com) wrote:
|
|
: Alan Cox (iialan@iifeak.swan.ac.uk) wrote:
|
|
: : vassili@cs.sunysb.edu (Vassili Leonov) writes:
|
|
|
|
: : >The original identity of the HAM radio is to be at the frontier and
|
|
: : >benefit the humanity - and free of charge... It's public service -
|
|
: : >running a NON-COMMERCIAL network on top of that is no contradiction.
|
|
|
|
: : ROTFL. The real motivation for most Governments allowing amateur radio is a
|
|
: : handy supply of radio trained people in case a war turns up.
|
|
|
|
: Back when knowing Morse code was considered a useful skill by the
|
|
: military, that was probably (at least partially) true. Does anybody
|
|
: besides hams use Morse these days?
|
|
|
|
Hi Grant!
|
|
|
|
Not trying to start any arguments or anything :) , but I know of some
|
|
(I'm sure there are others, but I don't know them) non-ham uses for
|
|
Morse these days that I've heard. :
|
|
|
|
Aircraft navigation and communication (the station ids
|
|
on omnis and such so you can tell which one you're
|
|
homing on)
|
|
|
|
Commercial repeaters (paging systems, etc.)
|
|
|
|
Some marine navigation beacons (I don't know very much about
|
|
these. )
|
|
|
|
-- Mark
|
|
--
|
|
"Linux! Guerrilla UNIX Development Venimus, Vidimus, Dolavimus."
|
|
============================================================
|
|
Mark A. Horton ka4ybr mah@ka4ybr.atl.ga.us
|
|
P.O. Box 747 Decatur GA US 30031-0747 mah@ka4ybr.com
|
|
+1.404.371.0291 33 45 31 N / 084 16 59 W
|
|
|
|
------------------------------
|
|
|
|
From: thomsen@cs.tu-berlin.de (Guenther Thomsen)
|
|
Subject: Re: memory leakage in 1.1.51 ? (FIX)
|
|
Date: 23 Sep 1994 16:17:15 GMT
|
|
|
|
|
|
'xcuse me, I'm sorry. It's not a bug, it's a feature ! Yes,
|
|
really. Since 1.1.? there is a new swapping strategy implemented:
|
|
pages swapped in (paged in from swap-space) aren't removed from the
|
|
swap- space like in older linux versions. This should improve speed,
|
|
if the pages are often swapped in but not modified. But the
|
|
disadvantage is, that you need now more swap space (like the old
|
|
sys5(?)-rule: 2 times your RAM), because now the max. usage of swap
|
|
space per process, if the process can't share memory with others, is
|
|
it's virtual memory size - the size of the text-segment, wich is
|
|
stored in the file system and is read-only.
|
|
|
|
So, if I start two gnuchessx processes, with a virtual size of about 8MB
|
|
each, and X is running and a few net daemons,gettys,xterms and shells
|
|
are sleeping, then the total virtual size is about 30MB. With 8MB RAM
|
|
I then have to offer about 20..30 MB of swap space. In this Example
|
|
Linux-1.1.51 used about 18MB, but it takes a while, until every page of
|
|
the processes is swapped out at least one time. The swap space usage
|
|
seems to grow, but it will reach a maximum.
|
|
|
|
Ok, not a bug, but for an 'old' linuxer somewhat strange.
|
|
|
|
PS: It may be a FAQ, or it will be. I have to say, that I didn't read
|
|
the recent ones ;-)
|
|
|
|
--
|
|
G\"unther Thomsen send eMail to thomsen@cs.tu-berlin.de
|
|
|
|
------------------------------
|
|
|
|
From: hjl@nynexst.com (H.J. Lu)
|
|
Subject: Re: Missing stdarg.h and (sort of) varargs.h
|
|
Date: 25 Sep 1994 17:09:30 GMT
|
|
|
|
In article <3644nl$g16@oak.oakland.edu>, srvance@unix.secs.oakland.edu (Stephen Vance) writes:
|
|
|> Has anyone noticed the conspicuous absence of stdarg.h? Or that there is
|
|
|> a <sys/varargs.h> which tries to include a non-existant <varargs.h>? This
|
|
|> is true of the 1.0.8 source tree as well as a 1.1.49 tree patched up from
|
|
|> a 1.1.29 base. It sort of complicates a port I'm working on, but I'll
|
|
|> create one for everyone if I need to.
|
|
|>
|
|
|
|
|
|
Just do
|
|
|
|
#include <stdarg.h>
|
|
|
|
it will be there. It is a magic :-). Seriously, your compiler was not
|
|
installed right. Where did you get your system? Slackware?
|
|
|
|
H.J.
|
|
|
|
|> Steve
|
|
|
|
------------------------------
|
|
|
|
From: s0017210@unix1.cc.ysu.edu (Steve DuChene)
|
|
Subject: more floppy problems with 1.1.51
|
|
Date: 25 Sep 1994 15:06:11 -0400
|
|
|
|
I applied the patch suggested to floppy.c (changing
|
|
if(filp->f_mode & 2) to if(filp && (filp->f_mode & 2)) and that
|
|
seemed to take care of the kernel dumps I was getting everytime
|
|
I umounted a floppy. However I had a umount go into uninterruptible
|
|
sleep yesterday and I am getting the following errors in /var/adm/
|
|
messages:
|
|
|
|
Sep 24 07:35:07 jaguar kernel: floppy: timeout
|
|
Sep 24 07:35:07 jaguar kernel: floppy I/O error
|
|
Sep 24 07:35:07 jaguar kernel: dev 024C, sector 2
|
|
Sep 24 07:35:52 jaguar kernel: floppy: unexpected interrupt
|
|
Sep 24 07:35:52 jaguar kernel: VFS: Disk change detected on device 2/28
|
|
|
|
I didn't get an kernel dump occurring though so I guess progress is
|
|
being made on this problem. BTW, I had several of these same error
|
|
message sets in the message file but not all caused the process to
|
|
go into uninterruptible sleep. It was only after mounting and
|
|
umounting several floppies in trying to clean up some of the
|
|
downloaded files that had been accumulating on my harddrive that the
|
|
sleeping process happened.
|
|
--
|
|
| Steven A. DuChene sduchene@cis.ysu.edu or s0017210@cc.ysu.edu
|
|
| Youngstown State University | Computer Science / Math / Mech. Eng.
|
|
|-------------------------------------------------------------------
|
|
| Friends don't let friends do DOS
|
|
|
|
------------------------------
|
|
|
|
From: mhp1@Ra.MsState.Edu (Michael H. Price II)
|
|
Subject: Warnings with libc 4.5.26.
|
|
Date: 23 Sep 1994 19:52:35 GMT
|
|
Reply-To: mhp1@Ra.MsState.Edu
|
|
|
|
Before I actually install libc-4.5.26, am I supposed to get a million
|
|
warnings while compiling it or should it compile quietly?
|
|
|
|
Michael
|
|
|
|
|
|
------------------------------
|
|
|
|
From: hpa@ahab.eecs.nwu.edu (H. Peter Anvin)
|
|
Subject: Re: A badly missed feature in gcc
|
|
Reply-To: hpa@nwu.edu (H. Peter Anvin)
|
|
Date: Fri, 23 Sep 1994 16:04:55 GMT
|
|
|
|
Followup to: <hpa.1c0f0000.I.use.Linux@ahab.eecs.nwu.edu>
|
|
By author: hpa@nwu.edu (H. Peter Anvin)
|
|
In newsgroup: comp.os.linux.development
|
|
>
|
|
> Append to the line immediately following it:
|
|
>
|
|
> %{!ansi:-lang-c++ %{c:-U__cplusplus}}
|
|
^^^^^^^^^^^^^^^^^^
|
|
|
|
Actually this turns out to be both redundant and incorrect. The best,
|
|
thus, I have managed to come up with is:
|
|
|
|
%{!ansi:-lang-c++}
|
|
|
|
This should work as long as there are no files in the C++ include
|
|
directories that conflict with any in the C include directories. I
|
|
haven't still figured out how to get it to properly pass the
|
|
-nostdinc++ flag if you are not compiling a C++ program. Nothing I
|
|
have tried has worked properly, so it is probably best to leave it
|
|
out.
|
|
|
|
--
|
|
INTERNET: hpa@nwu.edu --- Allah'u'abha ---
|
|
IBM MAIL: I0050052 at IBMMAIL HAM RADIO: N9ITP or SM4TKN
|
|
FIDONET: 1:115/511 or 1:115/512 STORMNET: 181:294/1 or 181:294/101
|
|
"NT is not a bad thing if I don't have to use it..." -- xmsb@borland.com
|
|
|
|
------------------------------
|
|
|
|
|
|
** 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
|
|
******************************
|