From: Digestifier To: Linux-Development@senator-bedfellow.mit.edu Reply-To: Linux-Development@senator-bedfellow.mit.edu Date: Sat, 26 Feb 94 14:13:07 EST Subject: Linux-Development Digest #501 Linux-Development Digest #501, Volume #1 Sat, 26 Feb 94 14:13:07 EST Contents: Re: Specialix driver (Chris Royle) Re: GOD SPEAKS ON LINUX! (Rikhardur Egilsson) Re: PLEASE use the GPL (Jon Brawn) Re: Specialix driver (Robert Sanders) Re: accessing BIOS Getting nuts... (Philippe Steindl) XRN with TERM support? (Gregory Larkin) Log Structured File System: Is there one ? (Amrik Thethi) Re: undefined symbols in modules (Erik Troan) Re: effectiveness of cache ram? (William Henning) Re: PLEASE use the GPL (Kai Henningsen) Re: Specialix driver (Kai Henningsen) Re: Context switch for pthreads (Alfred Longyear) RF Info on pty handling (Garrett D'Amore) kmalloc fails on 4096 bytes... what is the max now? (Theodore Ts'o) stty() and gtty() in C libs... (Theodore Ts'o) Serial problem with 0.99.15: tty65: input overrun (Theodore Ts'o) Bug in pl15f serial code (Theodore Ts'o) Re: linux.cf missing in X11/lib/config ? (R.C.Van-Den-Bergh) Re: How to create shared libs ? (R.C.Van-Den-Bergh) ---------------------------------------------------------------------------- Crossposted-To: gnu.misc.discuss From: Chris Royle Subject: Re: Specialix driver Date: Sat, 26 Feb 1994 14:43:15 GMT OK, here's a thought for you all. Linux is wonderful (that wasn't it..). However, if it is ever to get anywhere in the world on a serious foot, people *must must must* be able to provide systems for it which use source which they do not wish to disclose -- eg Motif. [And don't mail me and tell me the code concered is non-Linux - I know. And people who insist that the whole source to the microcode should be provided because of the GPL are off their metaphorical trolleys]. In arguing that Specialix cannot implement this driver for the reasons discussed, you are hindering the progress and usefulness of Linux. This applies not only to the Specialix case, but for others in the future, too. If Specialix won't do their driver for this reason, Linux will be seen by the world as something which could have been really excellent, but was hampered by the daft license it was issued under. If, on the other hand, Specialix (and anyone else in the same boat) are allowed to do their driver, then Linux will end up being seen as something very useful and going places. I'm disgusted by all this prevaricating that's going on. I suggest Specialix get on and do it. Think on it. Chris. -- Chris Royle "Come rest your head on these two" G&CC Undergraduate (Author: E. Hamlin) 0223 335436 car1002@cus.cam.ac.uk / c@royle.org (Internet) 0850 668151 car1002@uk.ac.cam.cus (JANET) ------------------------------ From: rikardur@rhi.hi.is (Rikhardur Egilsson) Crossposted-To: comp.os.linux.admin,comp.os.linux.help,comp.os.linux.misc Subject: Re: GOD SPEAKS ON LINUX! Date: 26 Feb 1994 14:12:14 GMT Plesae correct me if I'm wrong but the method god used was something like: 1 ) Joined a university in heaven with access to internet. 2 ) Learned how to spoof email by telnetting to port 25. 3 ) Wrote the whole message following the outlines of rfc1036. 4 ) Sent the fake message to news@localhost by using ( 2 ) Correct ? _______________________________________________________ | Rikhardur Egilsson | | | rikardur@rhi.hi.is | the void (shrunk 2x) | | TF3RET | | ======================================================= ------------------------------ From: jonb@specialix.com (Jon Brawn) Subject: Re: PLEASE use the GPL Date: Fri, 25 Feb 1994 23:45:55 GMT kenney@u.washington.edu (Michael Kenney) writes: >In article , >Piercarlo Grandi wrote: >>>>> On 23 Feb 1994 10:47:18 GMT, kevinl@bruce.cs.monash.edu.au (Kevin >>>>> Lentin) said: >> >[ stuff deleted ] >>Kevin> I am also having a hard time coming to terms with your statements >>Kevin> that a GPL somehow assures you of support >> >>Under the GPL anybody can provide commercial value added services (from >>distribution to support) for a piece of software, not just the authors. >> >>If the authors of a "non commercial use" piece of sw are no longer >>interested in distributing and supporting it, then it's basically dead >>in the water, as the only recourse is for each user to do their own >>support; but most companies would rather rely on professional support >>services, even for GPL software. >> >>If the software is GPL'ed, anybody can support it commercially, even if >>the original authors have decided to become jewellers or nuns or >>whatever. From the user's point of view ther GPL is a guarantee that the >>sw need not become orphaned. >> >Just because anybody *can* support it doesn't mean anybody *will*. The GPL >is no guarantee that there will be anyone supporting the software years from >now. BUT there is more CHANCE of it being supported. >If a piece of software becomes useful or popular enough it will stick >around and be supported *regardless* of the copyright/license. Look at X >and BSD. Ah, but for a piece of ``non-commercial-use-only'' software, this may well be ILLEGAL!!!! >---- >Mike Kenney >UW Applied Physics Lab >mikek@apl.washington.edu ------------------------------ From: gt8134b@prism.gatech.EDU (Robert Sanders) Subject: Re: Specialix driver Date: 26 Feb 94 00:40:29 GMT dholland@husc7.harvard.edu (David Holland) writes: >gt8134b@prism.gatech.EDU's message of 23 Feb 94 23:59:42 GMT said: > > I would posit that the Linux kernel is the only available implementation > > of the Linux kernel interface. The Linux kernel is GPL'ed, therefore > > any driver written to interface with the kernel is GPL'ed. Russ's > > assertion is correct in the eyes of the FSF. >All right. The Linux kernel is the only available implementation that >will run Linux binaries. Therefore Linux binaries have been created to >interface with the Linux kernel. The Linux kernel is GPL'd. Therefore, >everything which has ever been compiled to run under Linux is >automatically GPL'd. Sigh. PLEASE move this to gnu.misc.discuss. Better yet, drop it altogether. But since it's here, I don't think that follows at all. Linux binaries aren't linked into the kernel. Most Linux binaries are written to a more general interface, e.g. POSIX. The FSF position obviously wouldn't say that any programs that use GCC-specific extensions are auto-GPL'ed, nor that ELISP files are auto-GPL'ed, nor gawk..., etc. -- _g, '96 --->>>>>>>>>> gt8134b@prism.gatech.edu <<<<<<<<<--- CompSci ,g_ W@@@W__ |-\ ^ | disclaimer: <---> "Bow before ZOD!" __W@@@W W@@@@**~~~' ro|-So, the question remains : How do I get from protected mode : >to real mode and back ? : If you are talking about linux, then there is a vm86() call. I am not intrested in the v86 feature for my experiment - I want to know how to switch to real mode. Time to hit the books. Thanks anyway. Whitney ------------------------------ From: ilg@imp.ch (Philippe Steindl) Crossposted-To: comp.os.linux.help Subject: Getting nuts... Date: 26 Feb 1994 02:00:22 +0100 Hi Linuxers, hm .. is this a bug or not? I compiled pl15 with gcc 2.5.7 and libs 4.5.8. I am using dip 3.3.4 to get a slip connection working. This worked under pl14. Now, since pl15, my modem doesn't autoanswer an incoming call when using dip, even if the modem is on autoanswer (S0=2). I switched back to pl14 to check this and it worked again. Back again to pl15, it didn't. I recompiled getty_ps because I thought it could be the getty ... to no avail. The recompiled getty (newest I could find + c patches for pl15) didn't do any good. Now is this a bug of pl15, dip or something in the libs? thanx for any help Philippe Steindl ------------------------------ From: greg@equipe.viewlogic.com (Gregory Larkin) Subject: XRN with TERM support? Date: Sat, 26 Feb 1994 15:57:26 GMT Hi, I checked on sunsite, but it does appear that there is a copy of XRN with TERM support. Does anyone know if this has been done yet? Is there a FAQ somewhere that tells how applications using network code are ported to use TERM instead? Does anyone have any insight on how the Mosaic 2.2 with TERM support was done? Thanks, -- Greg Larkin Viewlogic Systems, Inc. Marlboro, Massachusetts, USA greg@Viewlogic.COM ------------------------------ From: at@setanta.demon.co.uk (Amrik Thethi) Subject: Log Structured File System: Is there one ? Date: Fri, 25 Feb 1994 14:27:25 GMT Is there, or will there be a log structured file system for Linux. This seems to be the trend in file systems in general, because of their inherent advantages. Is anybody working on a port or designing one from scratch? I thought of writing one, but I need more info on the best way to do it. -- Amrik Thethi. Tel. +223 421 008 Fax. +223 421 024 Setanta Software Ltd. Internet: at@setanta.demon.co.uk Cambridge, UK. ------------------------------ From: ewt@sunSITE.unc.edu (Erik Troan) Subject: Re: undefined symbols in modules Date: 26 Feb 1994 16:50:55 GMT In article <1994Feb26.105501.5976@pe1chl.ampr.org>, Rob Janssen wrote: >In <2klvfa$gtv@bigblue.oit.unc.edu> ewt@sunSITE.unc.edu (Erik Troan) writes: > >I think you should put the symbol in kernel/ksyms.S, the list of symbols >exported to modules. > Thanks to both of the repliers. I didn't see this file mentioned anywhere, but it is what I need. Thanks, Erik -- ======================================================================== "Could I bend yer ear fer a tick?" ewt@sunsite.unc.edu = Erik Troan sasewt@unx.sas.com - Strictly Ballroom ------------------------------ From: bhenning@bhami.wimsey.com (William Henning) Subject: Re: effectiveness of cache ram? Date: Sat, 26 Feb 1994 05:32:19 GMT In article <2khf69$8o9@jake.esu.edu> tbriggs@myhost.subdomain.domain (Tom Briggs) writes: >I believe, from my experience, that if you are talking 386, you want >as much cache as you can get. If you are talking 486, RAM cache is not >really all that extravagent. I have seen 486/33 DX with 64k, 128, and 256k >and all of them performed the same. The above is absolutely true for trivial benchmarks such as SI, Landmark, etc., that fit into the 8k on-chip cache. The above is FALSE for large programs. >Try this: If you can get access to a 486/33dx, run some benchmark program >and determine some reasonable measure of the system speed. Then, go into >your CMOS and disable the EXTERNAL ram cache, and run your benchmark again. >IF you see more than 1-2% difference, please let me know, and I'll gladly >eat these words. Now, if you want to see more, disable the INTERNAL & >EXTERNAL cache, and run your benchmark - your 486/33 is now performing >about like a 386/25... Now, for your final test, disable INTERNAL and >enable EXTERNAL, and see what it does to your performance... it helps, >but it does nowhere nearly as much as the 8k internal ram cache built >into your 486... thats the key... I did this a few months ago to prove the value of an external cache to some skeptics at work. Test setup: VLB Intel 486DX2-66, 256k cache, 16Mb ram, WD250 mb HD, OS/2 v2.1 Test: Compilation/linking of ~100k of C source code with icc. With internal/external caches enabled: about 2 minutes With internal cache enabled, external disabled: about 6 minutes With internal and external caches disabled: about 8 minutes With internal cache disabled, external enabled: about 3 minutes (Numbers from memory) >So, no, I would say that more memory is a better thing than more cache. More memory is ALLWAYS a good thing. If you swap a lot, cache efficiency gets lost in the time spent swapping. If you are not swapping, the more cache the better. >There are many many things that are better than having more cache. I've >got a 486/33 board with 64k cache -- I used to have 486/33 256k and I >never missed it at all..... Depends on what you are working on - if you are working on I/O bound programs you will not notice as big a difference. > Tom Briggs Bill -- ---- bhenning@bhami.wimsey.com - Linux & OS/2 user at home, OS/2 developer at work ------------------------------ Date: 26 Feb 1994 14:44:00 +0100 From: kai@khms.westfalen.de (Kai Henningsen) Subject: Re: PLEASE use the GPL becker@super.org wrote on 24.02.94 in <1994Feb24.051058.1397@super.org>: > There is another reason for using the GPL, even when you don't directly > profit from the code. It doesn't have the holes that a shorter copyright > notice has. A few days ago I ran across an error message that looked very > familiar. Verrryy familiar. I wrote it. I had distributed that code over > the net, the code *was* copyrighted, and it had my name and my employer's > name in the source, binary and documentation. The binary-and-documentation > package I got had no mention of the code's origin or original copyright. If > I had used the GPL instead of the "no-brand-name" copyright, I could point > out that removing the original copyright notice was an explicit violation of > the license. Without the GPL they'll probably claim that my code was > essentially public domain, and that they can distribute copies without > giving credit :-<. As I understand copyright (which is not that much), as long as you don't grant them any rights, the only rights they have is the fair use stuff. If there was a copyright mentioned, I do not see how someone can possibly be justified in removing it. They might not need to give more credit than is already there. But I don't see how they can remove any that is there, unless you explicitely allow them to. Kai -- Internet: kh@ms.maus.de, kai@khms.westfalen.de Bang: major_backbone!{ms.maus.de!kh,khms.westfalen.de!kai} ## CrossPoint v2.93 ## ------------------------------ Date: 26 Feb 1994 15:04:00 +0100 From: kai@khms.westfalen.de (Kai Henningsen) Subject: Re: Specialix driver becker@super.org wrote on 24.02.94 in <1994Feb24.170824.10684@super.org>: > under the copyright. It *is* a derivative work because it required the > unique existing GPL code to develop it. Few readers would disagree that a This can't be. Otherwise, each and every program built with gcc that uses *any* gcc extension would fall under the GPL, and the FSF explicitely states that this is *not* the case. > (non-trivial) patch file is covered under the terms of the original > copyright. Merely collecting such patch into a separate object file does > not change its status. (In contrast, if the code in question is a separate > and distinct program, then it is not covered by the original copyright.) Now here you argue that the original code is needed to *run* the beast. That is a completely different animal. Anyway, my copy of the GPL says > GNU GENERAL PUBLIC LICENSE > Version 2, June 1991 [...] > The precise terms and conditions for copying, distribution and >modification follow. > > GNU GENERAL PUBLIC LICENSE > TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION > > 0. This License applies to any program or other work which contains >a notice placed by the copyright holder saying it may be distributed >under the terms of this General Public License. The "Program", below, >refers to any such program or work, and a "work based on the Program" >means either the Program or any derivative work under copyright law: >that is to say, a work containing the Program or a portion of it, >either verbatim or with modifications and/or translated into another >language. (Hereinafter, translation is included without limitation in >the term "modification".) Each licensee is addressed as "you". [...] From this text, I do not see how it would be possible to argue that anything that needs GPL'd software to do anything useful falls itself under the GPL. On the contrary, it says quite clearly that it has to "contain" the original or a portion. In fact, with regard to patches, if patches were GPL'd by default, why does the FSF argue that it needs an explicit release for each and every patch before it can be integrated? I personally think that whoever argues that working-only-with-GPL'd-soft- makes-GPL'd has no leg to stand on. Kai -- Internet: kh@ms.maus.de, kai@khms.westfalen.de Bang: major_backbone!{ms.maus.de!kh,khms.westfalen.de!kai} ## CrossPoint v2.93 ## ------------------------------ From: longyear@netcom.com (Alfred Longyear) Subject: Re: Context switch for pthreads Date: Sat, 26 Feb 1994 17:27:46 GMT z1g192@rick.cs.ubc.ca (Christopher Andrew Smith) writes: >My questions are: >1) Since threads are contained within one UNIX process, do I have to > think about switching between Task State Segments, or is this only > a consideration when switching UNIX processes? No. Each process has one and only one TSS. There is no need to switch TSS blocks since you have only one to switch. >2) I know that I have to save the general registers. Do I have to save > all the segment registers? (ES,CS,SS,DS,FS,and GS) (ie is it possible > for one UNIX process to span across multiple memory segments?) Linux uses only a few values for the selector registers. When your user level code is executing, there is only one value. (Linux calls it USER_CS and USER_DS. They are presently 0x23 and 0x2B, respectively.) Like TSS values, you need only recognize that you will have only one value for the code selector and data selector(s). So, no, you do not need to switch these registers. Linux uses a "flat 32 bit" address space. The access to memory is controlled by the page tables, not by the descriptor tables alone. So, yes, there are "multiple" segments, if you consider that a segment is a shared block of memory such as "user code" and "shared library code" and "user data" and "shared memory data". However, they all fit within the 32 bits which are addressable by one selector. (It is the iNTEL processor which requires separate selectors for code/data, even if they point to the same address range.) >3) Does the context switching code have to run at a higher processor > privelege level than the usual user mode? There is only one privilege level for users processes. All user processes run at ring 3. What you do within the user code, you will always be at ring 3. >4) What are the calling conventions on the 386? I'm going to be > linking the context switch with C code, so I need to know: > > a) Where are procedure parameters passed? (the stack?) Parameters are pushed on the stack. You may find some additional insight if you write a small piece of code and then compile it with the "-S" option which leaves the assembly language file. answer = call_proc (p1, p2, p3); results in: pushl _p3 << pushed right-to-left for C language pushl _p2 pushl _p1 call _call_proc add $12,%esp << Discard parameters. Sometimes ignored if optimized. movl %eax,_answer << for fixed point scalars, result is in EAX. << for floating point, result is in fp(0) If you have a "structure" returned, the structure is pre-allocated on the stack and the address to this structure is passed as an additional parameter. Try compiling small code and looking at the assembly output. > b) Where do I put return values? (stack or general register) See above. >I'd appreciate if someone could help me with these questions, or point me >to the appropriate reference. There are many references. There are many good books on compiler design. For Linux, try Kernel Hackers Guide (khg* on sunsite's doc directory). For compiler design, I still like the "dragon" book (second edition). >Once I get the pthreads package working and stable on Linux, I will probably >make it public domain, with permission of the author of course, so the sooner >I can make it work, the sooner everybody can write threaded applications >on top of Linux. I am still of the opinion that threads are best implemented in the kernel as they are done in Windows NT, Chicago, and OS/2. However, pthreads is better than nothing. :-) Thanks. ------------------------------ From: garrett@netcom.com (Garrett D'Amore) Subject: RF Info on pty handling Date: Sat, 26 Feb 1994 17:28:24 GMT Hello Linuxers, I am trying to find information about the correct programming of pty's. Essentially, what I want to do is have a program that runs a shell, but examines all the data coming to or from the shell for a couple of escape sequences, and redirects data to "lpr" between certain escape codes. The program will be used as a layer of the linux (or other OS) console to allow it to work with my vtprint program. I'd like the shell to be unaware that it's not being run from a "true" tty -- e.g. the isatty() call in the shell should return true. So, a simple filter is unacceptable. I know it is possible to do what I want, because Xterm's do it, and I think even emacs does it. However, I have found it difficult to find information on this topic, and the xterm sources I have looked at have been difficult to understand. Can anyone out there *please* give me pointer to info on pty handling (a book, perhaps, or an on-line source of information?) Thank you very much. ================================================================= Garrett D'Amore | garrett@netcom.com Network Programmer/Analyst | Available for hire !! SDSU Computer Science Major | Go Aztecs! ================================================================= Ask me about Linux, the free 32-bit Unix-like OS for PCs! Also, ask for my resume if you are an employer in San Diego seeking a qualified network programmer or administrator. ------------------------------ From: tytso@ATHENA.MIT.EDU (Theodore Ts'o) Subject: kmalloc fails on 4096 bytes... what is the max now? Date: 26 Feb 1994 13:54:30 -0500 Reply-To: tytso@ATHENA.MIT.EDU (Theodore Ts'o) From: jmv@Rabbit.edu (jmv) Date: 25 Feb 1994 05:24:28 GMT The max kmalloc you can do is 4080. Why ? because there is a 16 bytes header. As far as I could tell (tell me if I am wrong), this is only defined in linux/include/linux/msg.h: #define MAXMSG 4080 This is only true if you have the Kernel debugging malloc option turned on. If it is off, then there is no 16 byte header, and you can malloc up to 4096 bytes. - Ted ------------------------------ From: tytso@ATHENA.MIT.EDU (Theodore Ts'o) Subject: stty() and gtty() in C libs... Date: 26 Feb 1994 13:54:30 -0500 Reply-To: tytso@ATHENA.MIT.EDU (Theodore Ts'o) From: pat@garion.it.com.au (Pat Mackinlay) Date: 23 Feb 1994 02:55:33 +0800 Hi all. Just a quick question to HJ or whoever's looking after the C library these days. The kernel would appear to have stty() and gtty() entry points, but these are not exported from any of the standard libraries (as of 4.5.19, anyhow). Up until now, I've been inserting: _syscall2(int,stty,int,fd,void *,sg); _syscall2(int,gtty,int,fd,void *,sg); into code that wants to use these BSD things, and it seems to do the trick. Could we perhaps see these in the BSD library at some stage? .... and this is how they are implemeneted in the kernel, which is why I suspect they haven't been implemented in the library. You're probably better off replacing them with the appropriate POSIX calls. asmlinkage int sys_stty(void) { return -ENOSYS; } asmlinkage int sys_gtty(void) { return -ENOSYS; } - Ted ------------------------------ From: tytso@ATHENA.MIT.EDU (Theodore Ts'o) Subject: Serial problem with 0.99.15: tty65: input overrun Date: 26 Feb 1994 13:54:30 -0500 Reply-To: tytso@ATHENA.MIT.EDU (Theodore Ts'o) From: steve@thelake.mn.org (Steve Yelvington) Date: Wed, 23 Feb 1994 20:06:14 GMT Benjamin Ryzman (zarkdav@eddy.frmug.fr.net) wrote: > I'm using an IDE disk, and I get this message (a lot of them actually) > while running ifcico (Internet to Fidonet Copy In/Copy Out) with Zmodem > protocol, while I don't get them when running Taylor's uucico with the > 'i' protocol... This thread is interesting; I'm having a similar problem, but it affects only the mouse port (cua0). It works fine until my modem port (cua2 or 3, interrupts 5 and 9, I've tried them both) is accessed. At that point the modem (internal DSI 14.4+) works fine, but the 1200bps serial mouse just freezes. Later I find the tty64 error message on a spare virtual screen. The mouse is an Identity 3-button model; I've tried it in both Microsoft and Mouse Systems modes. Once the modem port is free, the mouse comes back to life. I suspect it's a hardware problem; your modem is probably nuking IRQ 4, even when you have it configured to ise IRQ 5 or IRQ 9. (One possibility is that if your internal modem is configured using jumpers, that *two* jumpers have been installed, for both IRQ 4 and IRQ 5 or 9. If you're really lucky, that's the problem, and you can fix it pretty easily.) Try swapping out your internal modem with someone else's; it will probably fix the problem. - Ted ------------------------------ From: tytso@ATHENA.MIT.EDU (Theodore Ts'o) Subject: Bug in pl15f serial code Date: 26 Feb 1994 13:54:38 -0500 Reply-To: tytso@ATHENA.MIT.EDU (Theodore Ts'o) From: kevinl@bruce.cs.monash.edu.au (Kevin Lentin) Date: 22 Feb 1994 00:59:01 GMT I discovered a small problem in the serial drivers last night I think. I just put my internal modem back in my machine after a small absence (since before pl15 I'd say - maybe mid to late 14's) and it is configured on IRQ5. Unfortunately, Linux detect it at IRQ4. If I try IRQ2, Linux detects it as IRQ3. Needless to say this means that I can't use my modem on that irq which I really would like to do. Use the setserial program to set the irq at boot time. The automatic IRQ detection does not always work --- it's very dependent on your hardware system, and given the brain-damaged ISA bus, there's no way to make it dependable. - Ted ------------------------------ From: rcv@ukc.ac.uk (R.C.Van-Den-Bergh) Subject: Re: linux.cf missing in X11/lib/config ? Date: Sat, 26 Feb 94 17:26:08 GMT Hi, having installed slackware 1.1.1. a while ago (December), I seem to be missing /usr/X11/lib/X11/config/linux.cf (my /usr/X386 is a link to /usr/X11). Should I have one ? If so what is supposed to be in there ? At the moment, I have created my own file, based on x386.cf. (x386.cf was the only one with a reference to Linux in it). The reason I ask, is that I want to recompile InterViews 3.1 on my box, BUT I can't get it to work. The problem I have is (among others) that I am missing a number of config files. I have found *some* of them, and am improvising the others. Anyone with a valid /usr/X11/lib/X11/config/linux.cf, please mail me a copy.. CEdric -- Zhaumer, High Priest of Amalgaer, the dwarven God of Something. ------------------------------ From: rcv@ukc.ac.uk (R.C.Van-Den-Bergh) Subject: Re: How to create shared libs ? Date: Sat, 26 Feb 94 17:26:40 GMT Hi (again), anyone know where I can get some information on creating shared libraries ? I would like to limit disk space usage by making a shared version of libIV.a and libUnidraw.a (InterViews 3.1). Thanks, CEdric -- Zhaumer, High Priest of Amalgaer, the dwarven God of Something. ------------------------------ ** 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 ******************************