HDTenEightyP/NetNews huggingface dataset:
From: veit@du9ds3.fb9dv.uni-duisburg.de (Holger Veit)
Newsgroups: comp.unix.bsd
Subject: Re: codrv problems..
Date: 7 Jan 93 18:18:43 GMT
Organization: Uni-Duisburg FB9 Datenverarbeitung
Reply-To: veit@du9ds3.fb9dv.uni-duisburg.de
NNTP-Posting-Host: du9ds3.fb9dv.uni-duisburg.de
Keywords: 386BSD, codrv

In <1993Jan7.164904.41040@news.th-darmstadt.de> deeken@iti.informatik.th-darmstadt.de (Hans-Christoph Deeken) writes:

>In article <1993Jan6.184438.5175@lgc.com>, danson@lgc.com (Doug Anson) writes:
>> HI:
>> 
>[ description of codrv problems ]
>> 
>> I have the 386BSD 0.1 kernel with 1-58 patches applied + pcfs.

>Exactly the same problem here. Also "panic: syscall", also 386BSD 0.1.pl58.

>The kernel prints out the devices as they are probed/attached(?), but dies
>after that with a "panic: syscall", before /etc/rc output starts.
>The only occurance of panic("syscall") that I've found is in
>/sys/i386/i386/trap.c, at the start of syscall(). Since I don't know anything
>about the stuff done in trap.c, I'm stuck.

>> Any help would be appreciated.
>> Doug

>Me too. Holger?

>Hannes
>-- 
>Hans-Christoph Deeken | hannes@flinx.{RoBIN.de,hotb.sub.org} (home)
>Gerauer Str. 20       | deeken@iti.informatik.th-darmstadt.de (university)
>6000 Frankfurt/M 71   | IRC: Glenlivet
>      "Das Beispiel hinkt nicht, das sitzt im Rollstuhl" -- Marsi

The location of the panic("syscall") line is in trap.c, that's right. But
it does not tell anything about the real reason of the fault. Panic's occur
for a lot of reasons, but in this case it is indeed evidence that there is
still a bug in codrv-0.1.1. As Serge Vakulenko pointed out (in a private
letter), there is an uninitialized register variable in coprobe(), co_kbd.c.
The first declaration there should read
	register struct consoftc *p = &consoftc;

This might or might not be the bug which causes the trouble here, at least it
is worth trying. 

You may of course wait (a little bit ;-) ) for the next version.

Holger
-- 
|  |   / Dr. Holger Veit         | INTERNET: veit@du9ds3.fb9dv.uni-duisburg.de
|__|  /  University of Duisburg  |
|  | /   Dept. of Electr. Eng.   |          "Understand me correctly:
|  |/    Inst. f. Dataprocessing |     I'm NOT the WIZARD OF OS" (Holger)
Newsgroups: comp.unix.bsd
From: shipley@peyote.dis.org (Pete Shipley)
Subject: Re: 386bsd BOF at USENIX?
Organization: Processed People for a Processed America
Date: Mon, 4 Jan 1993 08:58:41 GMT


In article <CGD.93Jan2052055@stinson.CS.Berkeley.EDU> cgd@stinson.CS.Berkeley.EDU (Chris G. Demetriou) writes:
>
>   anybody interested in babbling at a 386bsd BOF at usenix?

yea...

>   if you're interested in talking about your favorite pet project,
>   or just think you're doing something important and wouldn't mind talking,
>   and will be at USENIX in San Diego in a few weeks, send me mail...


ok... I will...

--
---------------
Pete Shipley:
email: shipley@berkeley.edu             Flames:  cimarron@postgres.berkeley.edu
Spelling corections: /dev/null          Quote: "Anger is an energy"
From: mohta@necom830.cc.titech.ac.jp (Masataka Ohta)
Newsgroups: comp.unix.bsd
Subject: Re: INTERNATIONALIZATION: JAPAN, FAR EAST
Date: 6 Jan 93 19:49:50 GMT
Organization: Tokyo Institute of Technology

In article <1993Jan5.093059.29631@fcom.cc.utah.edu>
	terry@cs.weber.edu (A Wizard of Earth C) writes:

>>BTW, can you explain what XPG4 is?
>
>The internationalization mechanism following XPG3, the SVR4.2 standard for
>internationalization.  XPG4 is XPG3 with East Asian language support.

Then, XPG4 should be EUC.

>>>|> True. But, it should be noted that they don't fit even in 16 bits.
>>>
>>>Work is already under way to adapt Unicode to 32 bits.  I would be interested
>>>in any similar work you know of in progress for XPG4/JIS.

As a subset of ISO 2022, EUC allows for a 16, 24 or 32 bit character code
set.

>The primary use for an interntaionalization mechanism will be localization;
>anything on top of that (and yes, we can build multilingual applications
>on top of that with little effort) is gravy.

That is exactly the internationalization model of EUC, whose model is proven
to be useless for internationalization.

So, you don't have to prove it again with Unicode. Just use EUC.

						Masataka Ohta
From: titus@coombs.anu.edu.au (titus chiu)
Newsgroups: comp.unix.bsd
Subject: Re: [386 BSD] Permissions set wrong - HELP
Date: 5 Jan 1993 22:26:26 GMT
Organization: Coombs Computing Unit, Australian National University, Canberra.
NNTP-Posting-Host: 150.203.76.2
X-Disclaimer: This message was written by a user on Coombs at ANU. The
              opinions expressed are those of the user and not necessarily
              those of the Australian National University.

bde@runx.oz.au (Bruce Evans) writes:

>zip).  One advantage of cpio over tar is that it restores directory
>permissions so the default /tmp permissions would get fixed up by a
>/tmp with the correct permissions in another archive.

that is incorrect i am afraid ;) .. tar will restore permission for
root if the -p flag is used (i am pretty sure gnu tar has this flag) ..

cheers
.:. titus

>-- 
>Bruce Evans  (bde@runx.oz.au)


--
titus chiu                                   -- email: ---------------------
                                             ---- titus@coombs.anu.edu.au --
  dont drink and drive home                  ---- titus@turing.ORG ---------
  get stoned and fly home.                   -------------------------------
Newsgroups: comp.unix.bsd
From: witr@rwwa.COM (Robert Withrow)
Subject: Re: Dumb Terry
Keywords: Han Kanji Katakana Hirugana ISO10646 Unicode Codepages
Reply-To: witr@rwwa.com
Organization: R.W. Withrow Associates
Distribution: usa
Date: Thu, 7 Jan 1993 17:02:51 GMT

Hey chump:

If your intent is to impress people, I think you have succeeded.  I doubt
you are aware of the kind of impression you have made, are you?

-- 
 Robert Withrow, Tel: +1 617 598 4480, Fax: +1 617 598 4430, Net: witr@rwwa.COM
 R.W. Withrow Associates, 21 Railroad Ave, Swampscott MA 01907-1821 USA
Newsgroups: comp.unix.bsd
From: abe@netcom.com (David Abercrombie)
Subject: Doubles rounded when cast to int
Keywords: gcc, floating, integers
Organization: Netcom - Online Communication Services  (408 241-9760 guest) 
Date: Wed, 6 Jan 1993 14:33:37 GMT

Programs compiled on 386bsd using gcc 1.39 do not seem to 
cast doubles to ints correctly.  K&R says: "When the value of
a floating type is converted to integral type, the fractional 
is discarded...".  However, on my system (and on ref.tfs.com under
gcc 1.39), doubles get _rounded_ to the nearest int during a cast 
(instead of getting truncated).

Compiling with gcc 2.3.3 (on ref.tfs.com) provides programs 
that cast doubles to ints properly.

Why is this happening?  Feature or bug?  My own silly mistakes?
Is there a fix?

Thanks!
--
Dave Abercrombie                abe%lyra@infoserv.com
Oakland, CA                        abe@lyra.UUCP
(510) 652-7131                     abe@netcom.com

-- 
Dave Abercrombie                lyra!abe@infoserv.com
Oakland, CA                        abe@lyra.UUCP
(510) 652-7131                     abe@netcom.com
Newsgroups: comp.unix.bsd
From: old@corea.mumath (Olivier Dubois)
Subject: Re: Dumb Terry
Reply-To: old@corea.mumath
Organization: Sun Microsystems
Date: Fri, 8 Jan 93 10:43:38 GMT

I'm more a news reader than a news poster and I already observed several times
 Mr. Masataka Ohta, He is an expert at diverging a discussion, stating a 
provacal point of vue, responding with insult to every opposed argument, going
personnal in its insults....Most knowledgeable people forgave discussing with him,
he surelly has interesting points to raise, but he is so unfair in his arguments.

I saw several times the discussion going worse and worse. I know that the problem
of internationalisation is an important and complex one but I also know that
discussion will not be possible with Ohta san.

Lets hope that this discussion will continue on solid ground rather than muddying.

---
   __                         _____
  /  \ /\  o       o         ( /   )           o
 /   /| |     _     _  _    _ /  /     /_  _
 \__/_|/_/_/)/ |_/_(<_/____(_X__/_/_/_/_/_/_/_/_/)____

Olivier Dubois,
old@sunbim.be
c=BE;A=RTT;P=BIM;O=HORIZON;S=Dubois;G=Olivier

Newsgroups: comp.unix.bsd
From: adrian@rachel.ibmpcug.co.uk (Adrian Hall)
Subject: Machine crashes for no reason....Im out of ideas...
Organization: The IBM PC User Group, UK.
Date: Thu, 7 Jan 1993 17:55:29 GMT

A strange problem has started to occur recently on my machine. It seems
to enjoy rebooting for no reason whatsoever. No messages are usually
left. Occasionally, the message 

	Panic: kmem_map too small...
	Updating disks before rebooting.

Appears. Sometimes I get a vm_fault() error message (but rarely).

Anyone any ideas where I should even start looking???

Config is below for those interested.

Adrian
--
Config:

	Contaq 486/50 Motherboard AMI BIOS. Cache options 16Meg cached
		C0000-C8000 remapped. (Machine crashes straight away
		if I dont do this.)
	Western Digital WD-1009V ESDI Controller
		(Also serves the floppy drive)
	Adaptec 1542 SCSI Controller
	Novell NE-2000 Ethernet Controller
	2 x Serial Ports
		Dowty Trailblazer connected to COM1: running at 19.2K
		locked interface speed.
	1 x Parallel Port
	EGA GRaphics Card.

Kernel:
	Standard Distribution
	Patches 1-58 applied (removed extra return on Patch 19)
	Recently Posted NE-2000 driver
	Julians SCSI drivers.
	ESDI has standard boot-blocks, SCSI has new boot-blocks.
	New-Year Clock Patch
	Julians IP Memory-leak patch

machine		"i386"
cpu		"i386"
ident		RACHEL
timezone	0 dst
maxusers	32
options		XSERVER,INET,ISOFS,NFS,GATEWAY
options		"COMPAT_43"
options		"TCP_COMPAT_42"

config		"386bsd"	root on wd0 swap on wd0 and sd0

controller	isa0
controller	wd0	at isa? port "IO_WD1" bio irq 14 vector wdintr
disk		wd0	at wd0 drive 0
disk		wd0	at wd0 drive 1

controller	fd0	at isa? port "IO_FD1" bio irq 6 drq 2 vector fdintr
disk		fd0	at fd0 drive 0
disk		fd1	at fd0 drive 1

controller 	aha0	at isa? port "IO_AHA0" bio irq 11 drq 5 vector ahaintr
controller	scbus0

device		sd0
device		sd1
device		sd2
device		sd3

device		st0
device		st1
device		st2
device		st3

device		cd0
device		cd1

device		pc0	at isa? port "IO_KBD" tty irq 1 vector pcrint
device		npx0	at isa? port "IO_NPX" irq 13 vector npxintr
device		com1	at isa? port "IO_COM1" tty irq 4 vector comintr
device		com2	at isa? port "IO_COM2" tty irq 3 vector comintr
device		lpt1	at isa? port "IO_LPT1" tty irq 7 vector lptintr

device we0 at isa? port 0x280 net irq 2 iomem 0xd0000 iosiz 8192 vector weintr
device ne0 at isa? port 0x300 net irq 2 vector neintr
device ec0 at isa? port 0x250 net irq 2 iomem 0xd8000 iosiz 8192 vector ecintr

pseudo-device	loop
pseudo-device	ether
pseudo-device	log
pseudo-device	pty	32

pseudo-device	swappager
pseudo-device	vnodepager
pseudo-device	devpager
-- 
------------------------------------------------------------------------------
Adrian Hall				Telephone: +44 (0)81 863 1191
Connect Systems Manager			Fax:	   +44 (0)81 863 6095
The IBM PC User Group			Internet:  adrian@ibmpcug.co.uk
From: eddy@aludra.usc.edu (George Edmond Eddy)
Newsgroups: comp.unix.bsd
Subject: Multicast update...
Date: 10 Jan 1993 13:40:51 -0800
Organization: University of Southern California, Los Angeles, CA
NNTP-Posting-Host: aludra.usc.edu
Keywords: multicast


this is just a brief word to update the status of what i have done
with/to Steve Deering's ip multi-cast extensions.  Over the holidays
i got a working kernel at home, i'm a little concerned with my treatment
of the mbuf stuff.  More specifically, in previous versions mbufs where
added to and trimmed from directly with the m_off and m_len structure
fields, m_off no longer exists.  I used the routine m_adj to adjust
mbuf's accordingly.  If anyone can impart some words of wisdom i would
be grateful 8-).  I am now able to join a multicast group...

I am now adding the multicast extensions to the 386bsd version of
netstat, i've got some bugs to hunt down and fix.

Up until now this has all been done on a standalone system 8-/.  I
have recently procured another 386 and 2 ethernet cards for $150 (not
bad eh?) so i will need to do work on the ethernet drivers for the 
cards i have (3com and WD).  So i could actually test the stuff on
a wire.  Hopefully before too long i will be able to scrounge together
a 386 box at work from the Windows army, so i can test the multicast
stuff on a "real" network with a few suns.

This is my first attempt at doing any kernel work other than just cruising
aroundand making minor fixes, so any comment or criticisms will be 
greatly appreciated.  

someday i will provide the port to all interested when i become reasonably
confident the stuff works at beta-quality.  unfortunantly this will take
me quite a bit longer than someone that knows what they are doing.

adious, for now.

--

- rusty

rusty@rockwell.com
eddy@usc.edu
Newsgroups: comp.unix.bsd
From: corcoran@valhalla.cs.wright.edu (Michael P. Corcoran)
Subject: SOLUTION to 386bsd problem of panic:can't mount /
Organization: Wright State University
Date: Tue, 12 Jan 1993 05:15:17 GMT

The problem:
I posted a message a couple of days ago saying that I could not
get 386bsd to boot correctly because it kept failing with a message
panic: "can't mount root"
I found that the disk label was being corrupted whenever I rebooted.
 
The cause:
The disk controller was mapping the 1632 Cyls 8 heads into 1024 cyls 
16 heads to overcome the dos 1024 cyl limitation.  BSD was trying to 
use the "real" mapping while DOS was trying to use the translated 
mapping and they conflicted.  
(thanks to ejh@slustl.slu.edu for pointing it out!)

The solution: 
My solution was to simply tell the controller to use native 1 to 1 mapping.
This was an option in the ROM setup program in the controller run by
getting in through DOS debug and then -g=c800:5.
This causes DOS to think the entire disk is only about 200 Meg (out of 360)
but I don't care.  The dos partition only uses the first few sectors anyway.
BSD correctly sees that dos partition and reports the right number for
the amount of disk left (total - dos).

So I'm on my way to an endless wonderland in bsd, installing and maintaining
yet another OS on top of the 60 Sun and Dec workstations I already help
to maintain.

Now I have to install X and a billion patches.... <yawn> time for sleep.

Mike

-- 
_____________________________________________________________________________
 Michael P. Corcoran, Computer Systems Engineer (corcoran@cs.wright.edu)
 College of Engineering and Computer Science	FAX  :(513) 873-5009
 Wright State University, Dayton, Ohio.  	VOICE:(513) 873-5157
From: gambert@screamer.csee.usf.edu (Allen Gambert)
Newsgroups: comp.unix.bsd
Subject: encrypted passwds on 386bsd
Date: 2 Jan 93 18:59:19 GMT
Organization: University of South Florida at Tampa

I remember reading awhile back on how to add encryption in the passwd file.
I lost the copy of the file and I would know like to add this feature.

Does anyone know how this can be done?  Do I just need to add the crypt function
to one of the libraries and then change the login program so it calls 
getpass.  I would then crypt the passwd and then compare it to the encrypted 
copy in the passwd file.  Is this all I need to do or is there more.  Any help
would be appreciated.

Allen
Newsgroups: comp.unix.bsd
From: ellis@nova.gmi.edu (Stew Ellis)
Subject: Re: 386BSD.EXE - Let DOS handle booting?
Organization: GMI Engineering&Management Institute, Flint, MI
Date: Tue, 12 Jan 1993 21:24:25 GMT

peter@ferranti.com (peter da silva) writes:

>In article <C0q94w.48p@NeoSoft.com> karl@NeoSoft.com (Karl Lehenbauer) writes:
>> Hey, how about making the second stage boot, say Julian's loader, an
>> executable DOS program?

>This is what Plan 9 does. I was at first repelled and disgusted, but on
>reflection it sounds like a really nice idea. It would resolve the Compaq
>boot problem, it would resolve the problem of video boards that require
>magic DOS configuration programs, it would resolve the "how do I boot
>386BSD on a second controller" problem, and so on.

>Plus, it'd make it easier to hack around with the boot sequence. You could
>build a new boot program without worrying about making your system non-
>bootable. You could give it arguments

>	bootbsd boot-options where init-options

>	bootbsd as1a:386bsd.old
>	bootbsd -large wd0a
>	bootbsd -debug fd0a
>-- 
>Peter da Silva                                            `-_-'
>Ferranti International Controls Corporation                'U` 
>Sugar Land, TX  77487-5012 USA
>+1 713 274 5180                            "Zure otsoa besarkatu al duzu gaur?"

But is MSDOS as powerful an OS as the forth boot monitor on a Sun SPARC?

--
                                                          ___________________
  R.Stewart(Stew) Ellis, Assoc.Prof., (Off)313-762-9765  /   _____  ______ 
  Humanities & Social Science,  GMI Eng.& Mgmt. Inst.   /        / /  /  / /
  Flint, MI 48504      ellis@nova.gmi.edu              /________/ /  /  / /
From: jcargill@oka.cs.wisc.edu (Jon Cargille)
Newsgroups: comp.unix.bsd
Subject: [386bsd] Has anyone used 2.8 Meg floppy drives with 386bsd?
Keywords: Han Kanji Katakana Hirugana ISO10646 Unicode Codepages
Date: 8 Jan 93 16:34:53 GMT
Organization: University of Wisconsin-Madison CS Dept


Has anyone used a 2.8 Meg floppy drive with 386bsd?  I'm considering
getting one.  Although the media isn't cost-effective right now, I'm
hoping that it will eventually drop in price.

Does anyone know what kind of controller interface is required for
these 2.8M drives?  I've seen some controllers advertised as "2.8 Meg
compatible".  Does that mean most controllers are incompatible with
the 2.8M drives?  Anyone know specifically whether an Adaptec 1742 or
a Bustek 742 will work with them?

Any information is appreciated.

Jon
-- 
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.
Jon Cargille		jcargill@cs.wisc.edu
Want your .sig compressed?  Reasonable rates
and fast turnaround. Call today!
From: jrb@rigel.cs.pdx.edu (James Binkley)
Newsgroups: comp.unix.bsd
Subject: setitimer bug revisited/signal question/midi/mpu
Date: 8 Jan 93 22:59:07 GMT
Article-I.D.: pdxgate.6679

I've been trying to figure out why the "real timer" in
setitimer was "unreal"; i.e., you couldn't do better
than 10Hz.  You should be able to.  The real timer
works correctly on BSDI and sun boxes with the code
I posted before. On 386bsd, you could never get
better than 10hz; i.e., 10 interrupts per second.
You should be able to get somewhere up to around 100hz
(but not quite).  I also discovered that the same
thing was true for the other two setitimer timers,
profiling, and virtual (limited to 10hz).  The problem seems to be based
on the fact that code in kern/kern_sig.c/psignal()
has changed (say from 4.2 BSD) 
so that in a lot of circumstances, need_resched() is
*not* called. In the past, I believe any signal would cause
rescheduling to occur. Here it won't occur until the 
round-robin daemon runs at 10 times a second... So to quote
a long departed political leader: "what is to be done?"  

As an experiment, I tried blatantly toggling want_resched
like so in realitexpire() in kern/kern_time.c. 

/* kern/kern_time.c
*/
realitexpire(p)
...
{

	extern int want_resched;

	want_resched++;
	psignal(...);
	...

This routine
is called as a timeout routine by setitimer(2) when the
"real timer" is started. The result was the real interval
timer worked correctly.  Here's a possible suggestion
as to one approach (what do other people think?).  I think
psignal should be altered so that when any of the 3 signals
used by setitimer are called, need_resched is called.  I need
to look at the kern/kern_sig.c code a little more.  

And now for the midi/mpu part.  I've been working on a "sequencer" --
trying to port it to UNIX from dos.  I have a simple mpu401 driver
if anybody wants it, and I'll get around to getting the sequencer
put out someplace for ftp'ing in a bit.  (It needs some aging
and I've got some curses work to do first).
The cute part was that I just played Bach's Fugue #9 from the Art of the Fugue
on a UNIX box. I've always maintained that music wasn't very real-time.
Of course, I wasn't hooked to a network and wasn't running sendmail
in the background... it worked fine.

				Jim Binkley
				jrb@cs.pdx.edu
Newsgroups: comp.unix.bsd,comp.std.internat
From: jlu@cs.umr.edu ( Eric Jui-Lin Lu )
Subject: [386BSD] looking for zmodem ....
Date: Wed, 13 Jan 1993 04:18:48 GMT
Organization: University of Missouri - Rolla

Hi *,

Thanks to Sagg.  Finally, I have seyon up and running.  However,
I need a working zmodem program.

When I transfer text file by using zmodem, it works fine; however,
it doesn't work if the file is compressed (filename.Z).  I have tried
the zmodems from the core distribution and the one in nova.
Thanks!!


  --Eric

-- 
***************************************---       Grad. student          ---*
* Obviousness is always the enemy of  *   \     Jui-Lin Lu (Eric)      /   *
* correctness.  -- Bertrand Russell   *   /      jlu@cs.umr.edu        \   *
***************************************---   Univ. of Missouri-Rolla    ---*
Newsgroups: comp.unix.bsd
From: danson@lgc.com (Doug Anson)
Subject: codrv problems..
Keywords: 386BSD, codrv
Organization: LandMark Graphics Corporation LGC
Date: Wed, 6 Jan 1993 18:44:38 GMT

HI:

I tried installing the latest codrv package (keycap-0.1.1.tar.Z). I ran into
several problems with /sys/i386/i386/conf.c. I _REMOVED_ the pc0 interface
definition from my config file and installed the co0 interface as told by the
instructions. As a result, I got an unresolved error in /sys/i386/i386/conf.c
(pcmmap to be specific) when compiling the kernel. 

Well, I decided to ifdef the pccons stuff (i.e. if NPC > 0 ...) as is done with
other drivers in conf.c. I managed to get the kernel recompiled successfully.
However, In addition, I made the /dev/vga and /dev/kbd as instructed with the
correct major device numbers coresponding to conf.c. However, my kernel now
reboots continuously on a syscall panic.

I have the 386BSD 0.1 kernel with 1-58 patches applied + pcfs.

Any help would be appreciated.
Doug

-- 
-------------------------------------------
Doug Anson					
Internet: danson@lgc.com			
Phone:	  713.560.1274
FAX:	  713.560.1277
SNAIL:    Landmark Graphics Corporation LGC	
	  15150 Memorial Drive
	  Houston, TX 77079			
-------------------------------------------
Xref: sparky comp.unix.bsd:11096 fj.os.386bsd:249
From: mhiroshi@tansei.cc.u-tokyo.ac.jp (H. Murakami)
Newsgroups: comp.unix.bsd,fj.os.386bsd
Subject: [386bsd] Strange behavior of the system.
Date: 10 Jan 93 16:35:37 GMT
Followup-To: comp.unix.bsd
Organization: Hokkaido Univ. However I am subject to tansei for JUNET.

To: comp.unix.bsd,fj.os.386bsd
Subject: [386bsd] Strange behavior of the system.

I encountered a unbelieavable behavior of the system now.
If I linked the object files using gcc2 then the executable
outputs just two warning.
However, if I make the object archive first, and then
link is made using the gcc2 for the object and the library,
the result is different!

How this can be possible????

 

Script started on Sun Jan 10 11:50:05 1993
% ls -l *.o
-rw-r--r--    1 hiroshi       779 Jan 10 11:46 atof.o
-rw-r--r--    1 hiroshi     70373 Jan 10 11:46 enquire.o
-rw-r--r--    1 hiroshi      8045 Jan 10 11:46 vfprintf.o
% 
% 
% gcc2 enquire.o atof.o vfprintf.o -o a.out
% a.out | grep WARNING
*** WARNING: Possibly bad output from printf above
*** WARNING: Possibly bad output from printf above
% 
% rm mylib.a
% ar ruv mylib.a atof.o vfprintf.o
ar: creating archive mylib.a.
a - atof.o
a - vfprintf.o
% ranlib mylib.a
% gcc2 enquire.o mylib.a -o a.out
% a.out | grep WARNING
*** WARNING: Possibly bad output from printf above
*** WARNING: Possibly bad output from printf above
*** WARNING: Possibly bad output from printf above
*** WARNING: Possibly bad output from printf above
% exit
Script done on Sun Jan 10 11:51:12 1993