From: Digestifier To: Linux-Development@senator-bedfellow.mit.edu Reply-To: Linux-Development@senator-bedfellow.mit.edu Date: Tue, 1 Mar 94 08:13:04 EST Subject: Linux-Development Digest #511 Linux-Development Digest #511, Volume #1 Tue, 1 Mar 94 08:13:04 EST Contents: Re: Linux and X WordPerfect (Eric Youngdale) GCC/++ Shared Linkage (Iain Bryson) CThreads (D. Robert Adams) LINUX FOR SUN (Stuart Tener) Attention Linux Adaptec developers (David Rapchun) Help! GCC errors (Dean Junk) Re: sysvinit-2.5 and bash-1.13.5 problem! [SOLUTION] (Neal Becker) Re: Serial problem with 0.99.15: tty65: input overrun (Roland Rosenfeld) Re: Specialix driver (Tim Smith) Re: Specialix driver (Raul Deluth Miller) Re: Specialix driver (Robert Sanders) Re: GOD SPEAKS ON LINUX! (Alan) Lint for Linux? (Niels J. Bagger) Re: [ANSWER] Re: ipcs utility (David Bonn) High dot freq. (94.5Mhz) => some miscoloured pixels (Kraen David Christensen) Re: Serious 80386 bug (Rafal Maszkowski) ---------------------------------------------------------------------------- From: eric@tantalus.nrl.navy.mil (Eric Youngdale) Subject: Re: Linux and X WordPerfect Date: Tue, 1 Mar 1994 03:04:12 GMT In article <2ktvff$cbc@bradley.bradley.edu> guru@camelot.bradley.edu (Jerry Whelan) writes: > Other than the size difference, is there any technical reason why >Linux shouldn't just adopt the ELF format as the native binary format? >(Debugging C++?) Yes. The GNU as and ld do not support ELF shared libraries. No one is working on this right now, so it is not at all clear when this will become available. Switching the native format has been discussed, but until we get gas and ld going it will just be idle talk. If anyone wants to dig into the bowels of ld and bfd (not for anyone with a weak heart), this would make a good project. -Eric -- "The woods are lovely, dark and deep. But I have promises to keep, And lines to code before I sleep, And lines to code before I sleep." ------------------------------ From: iain@ECE.Concordia.CA (Iain Bryson) Subject: GCC/++ Shared Linkage Date: Tue, 1 Mar 1994 00:31:56 GMT Hi all. I've been writing code with Linux for a while now, and only just recently 'noticed' the file sizes of my executables. They're so big I came to the cerebral conclusion that they are NOT using the shared libraries (300K for an small X proggie). How do I USE the shared libraries? If there is a standard way, will the same makefiles work with SunOS also? Thank-you (please use e-mail.) -- _________________________________________ ______________________ / Iain Bryson, Montreal, Quebec, Canada. \/ Things I do: \ | iain@ece.concordia.ca - for the time ||C/++, perl, UNIX, X, | | being ||lie about things I do.| \_________________________________________/\______________________/ _________________________________________________________________ / "Now we're cooking with evil gas!" - Sir Simon Milligan, KITH \ \_________________________________________________________________/ ------------------------------ From: adams@ms.uky.edu (D. Robert Adams) Subject: CThreads Date: 28 Feb 1994 20:09:08 -0500 I'm looking for a C-Threads package for Linux. Is there such a thing? -Robert adams@dcs.uky.edu University of Kentucky Department of Computer Science ------------------------------ From: stuart@jane.sas.upenn.edu (Stuart Tener) Subject: LINUX FOR SUN Date: 1 Mar 1994 03:44:56 GMT LINUX FOR SUN (IPC, IPX, Classic, LX, etc.) Does it exist? where do I get it? what will it cost? reply via email: stuart@jane.sas.upenn.edu (310)-358-0202 thanks ------------------------------ From: rapchun@jawbreaker.sdsu.edu (David Rapchun) Subject: Attention Linux Adaptec developers Date: 1 Mar 1994 01:30:40 GMT Hello, I need some help. I recently got a new Adaptec 2742T controller and sold off my 1542B thinking I must press on with future development to stay current. My main mission is to run Linux and I cant because it wont recognize this card. To whoever is writing the driver (hopefully you r reading this now) could you please give me some feedback on the status. Thanx a lot. Dave. -- _oI=vo__ ?/$="'" """^SATAN$~\ .&?/' `""$$, ,/?/' /-"^\. .-=~\T, ,/?/' /SATAN| |\IS,&' |LT `\?\\ ``\?\^I/HATE@:~:$=v\. `$k==v\.??\, `\d `\$$'9P'I-LOVE=SATAN\/$$~?$\ ,R/ /$?~^'"""""`"\\&&< ?b "`~$P:c: /v==v,#::?<<&:'T| d$/' [|:. ""=o/&. ,P o&Z'`'.##| |MH\|| ,$$' `=:$H&=\. `"b?b. .&' 96*.-v.:?/`\==$&?$&*' `^$?\. `*&*\\ ,P ?~-~' |$$S>' `\7b ,T/\&&\. d? |T' \/b .&J' `\> d' T, &`L /|| ?| ?, ||9 J\T H ?, H|| ||/ || 9, ||M PJ' || `H bT, ||T || || T/L H|| `b M &T, M| 9, 9 `L9, M| `&. | `?*,9|| `b d `\?(|H. `b ?b `*\ `&. `\. J*|b `\o/\. `&. ,P 9/L 9:&. `9\ ?? `H9. *?9\ `b .&' |/| `|`\. `L ./' `|H d\/qZbo. M .,=' ,|T ./~&$$?=??/' `"=H$| H .o='' J\| ,*/'' `\? `' ./?ov=="*b9, ,$P ,Td ,$$'`' ?|M ,$/ J|| ,$?/ M|| ?$/ M|| |>\. ._,~9$'' T|| d'M. 9`| `Hi:R&:&&6&="' ./$J| `^"\Z\. ||M `=Z\:"" H|T" `&H&>v_ bT, .. v,?|\ M|| .:Z|&\. ||H _DEATH~>TO9H| `?*\ ?$`#'H 9ALL|1KIDS* .$/ `bZ&\ ,o\&KILL&/' \?$.:?ooo/*""' `\$$b_ |\MAIM*:./' `"""' `' `~?&qDESTROY#/' "^~DIE/" ****************************************************************************** * No one shall wield Excalibur but me! * * Give us the eye! * * When I left you I was but the learner, now I am the master! * ****************************************************************************** * Rapchun@suicide.SDSU.edu * ****************************************************************************** ------------------------------ From: us292121@bulldog.mmm.com (Dean Junk) Subject: Help! GCC errors Date: 1 Mar 1994 05:13:26 GMT I just upgraded to .99.15 kernel from .99.14 kernel along with the following libraries: ld.so.1.4.3 libc.so.4.5.21 libm.so.4.5.21 and the following tar archives: image-4.5.21 inc-4.5.21 I am having the following problem compiling xmix: /usr/lib/libgcc.sa(__libc.o): Definition of symbol __NEEDS_SHRLIB_libc_4 (multiply defined) /usr/lib/libc.sa(__libc.o): Definition of symbol __NEEDS_SHRLIB_libc_4 (multiply defined) make: *** [xmix] Error 1 Do you have any ideas? I have everything else working great but this! System setup: 386DX-40 AMD 16MB Memory 2-250 WD IDE HD's Mitsumi CD-ROM SB Multi-CD 16 card Conner 250MB Tape Backup 3.5" Floppy 5.25" Floppy 14400 Pract Per modem Linux .99.15 from sunsite.unc.edu gcc 2.4.5 xfree 2.0 Thanks, -- Dean Junk "An ounce of perception, a pound of obscure" Internet (dpjunk@mmm.com) --RUSH ------------------------------ From: neal@ctd.comsat.com (Neal Becker) Crossposted-To: comp.os.linux.admin,comp.os.linux.misc Subject: Re: sysvinit-2.5 and bash-1.13.5 problem! [SOLUTION] Date: 28 Feb 1994 22:08:45 GMT Seriously, here is a real solution. Use 'killall' that comes with sysvinit-2.5. Works fine. Yes, my problem was that I had a full-featured /bin/bash and a stripped-down /bin/sh. But killall works fine in any case. But you need to use the killall that comes with sysvinit-2.5, and not some other thing that happens to have the same name but does something different :( ------------------------------ Date: Mon, 21 Feb 1994 15:12:35 MET From: Roland_Rosenfeld@p13.flokiste.fido.de (Roland Rosenfeld) Subject: Re: Serial problem with 0.99.15: tty65: input overrun Hi! Lcvanveen (lcvanveen@et.tudelft.nl) wrote: > >> Feb 5 14:05:44 whitney kernel: tty65: input overrun > >> I *DO* have a 16550A, and while I do have the serial port cranked up to > >> 57.6k, I only have a 9600 hooked up to it, and a .gz file is not > >> very compressible, > I use 0.99pl13 with a normal (slow) 16450 chip and it even runs > without trouble when doing 38k4 on a null-modem line. Maybe you got > something wrong with the inittab and other setting files. Try looking > around there first. Lucky one! It realy isn't normal that 38400 works with an 16450 without problems if there ist much traffic on the line. If you use only a simple terminal on the other side of the line, you won't run into problems, but if you use it with term and uploads per term, there is much more traffic and more errors occure. I switched down the speed from 38400 to 19200 on the Linux-PC and on the Sun on the other side and the errors gone away and the speed rises from 1000-3000 CPS to 2000 CPS constantly). Bye Roland -- * Roland_Rosenfeld@p13.flokiste.fido.de * Fido: 2:2450/300.13 * ------------------------------ From: tzs@u.washington.edu (Tim Smith) Crossposted-To: gnu.misc.discuss Subject: Re: Specialix driver Date: 1 Mar 1994 09:07:27 GMT Wayne Schlitt wrote: >> Given the potential legal problems outlined above (I think there were 75 >> different interpretations in those 100 messages), most of us are willing >> to "just say no" and focus in a market w/o these hassles. > >First: > > Don't listen to us random net loonies. We have no power to back up > our words. There are more ways to back up words than suing. If a bunch of random net loonies go around telling potential users of your product that the product is illegal, immoral, frightens horses, and spoils milk, that can hurt sales even if none of it is true. --Tim Smith ------------------------------ From: rockwell@nova.umd.edu (Raul Deluth Miller) Subject: Re: Specialix driver Date: 28 Feb 1994 22:26:38 -0500 Is anybody that cares reading this stuff? Donald Becker: > ... 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 ... Kai Henningsen: 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. This is an irrelevant issue -- though one I've seen much comment on. Programs produced by gcc are no more copyrighted than programs editted by emacs. The gcc libraries [which may be held analogous to blank form letters] have a special license on them different from the standard gpl. gcc isn't the issue here -- the serial driver won't be part of gcc. Linux is the issue here. > ... (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.) Ther are several issues that might be relevant here: (1) original form of the code [some code is _written_ in machine language, for instance]. (2) maintainability of the code [a hex dump under gpl can be analyzed and modified -- this is completely different from a sun "you hereby agree to never look at our code" license]. (3) legal precedent [best leave that one to the courts]. (4) flamage [I see a lot of this]. (5) propriatary considerations. As best I can see, including a hex dump in a gpl'd source is legal but not necessarily the best idea. The hex dump can't be put under a separate license if it's part of Linux. The hex dump is harder to maintain than some kind of source, but if there is no expedient way of including the source on Linux, then it isn't really source [though it might be included as documentation]. If the object is keeping the code proprietary, then including it in a Linux kernel isn't the way to achieve that end. For example, there's nothing to stop Microsoft or Novell from redistributing Linux under the current license terms. Raul D. Miller ------------------------------ From: gt8134b@prism.gatech.EDU (Robert Sanders) Subject: Re: Specialix driver Date: 1 Mar 94 06:35:51 GMT tzs@u.washington.edu (Tim Smith) writes: >Donald J. Becker wrote: >>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 >That's not what "derivative work" means. To be a derivative work, it >must in some form incorporate a copyrighted portion of the work it >is alleged to a derivative work of. I don't mean to insult you, but it really surprises me how many people think this is the news we've all been waiting for. YOU ARE BEGGING THE QUESTION. The whole debate comes down to whether a "derivative work" must actually incorporate copyrighted code in this work's distribution, and what "incorporate" actually means. If I distribute .o files to link into the kernel, having included none of the include files and used no .c files distributed with the kernel, have I not created a derivative work? If not, then the GPL is and has been meaningless for a long time. Prior cases like this (though not exactly like), such as the NeXT/Objective-C case, seem to say that this is indeed a derivative work. Now, people are arguing that drivers loaded into the kernel via the "modules" code are not covered by the GPL. Eh? Has anyone looked at what the 'insmod' program actually does? It's a link editor. It's basically just 'ld' with some kernel hooks. Looks like a clear case to me. If linking NeXT's Objective-C .o files with gcc was a case of *NeXT* creating a derivative work, then linking Company X's .o files into the kernel is also. And, yes, before anyone else announces it, I think we all recognize that the Specialix download driver must be available as source, but the downloaded code need not. -- _g, '96 --->>>>>>>>>> gt8134b@prism.gatech.edu <<<<<<<<<--- CompSci ,g_ W@@@W__ |-\ ^ | disclaimer: <---> "Bow before ZOD!" __W@@@W W@@@@**~~~' ro|- some miscoloured pixels Date: 24 Feb 1994 14:06:00 GMT Environment: Linux running Xfree 2.0 (from slackware 1.1.1) on a 386-40 with 387 128kB cache, 8 MB RAM, ISA bus. I have a S3-801 chip based graphiccard (1 MB DRAM) and a 17" eizo F550i. I run 1152x800 non-interlaced. First I did so with a dot freq. at 75 Mhz, but that noly gave round 60Hz screen-update freq. While both card and monitor can do better I rasied the dot freq. to 94.5 Mhz witch gave a much more flicker free picture. But when many colours are in use on the screen, some pixels on the screen (very few) gets a wrong colour (at a dot freq. at 75Mhz this does not happen!). I can then refresh screen from the menu in openwindows and the screen is fine again. Trying to locate why, I also tried down-accelerating my cpu to 20Mhz after which there was no problem, except from the loss of performance. [It seems to me that it is a conflict between the 386-40 cpu and the S3-801 chip in acces to the 1 MB DRAM on the videocard?] Anybody have a reasen or a solution I would like hearing about it. -- / Kraen D. Christensen ------------------------------ From: rzm@oso.chalmers.se (Rafal Maszkowski) Subject: Re: Serious 80386 bug Date: Tue, 1 Mar 1994 08:20:47 GMT WE Metzenthen (billm@jacobi.maths.monash.edu.au) wrote: > Running 'crashme' on my Linux system for a few hours caused my > machine to hang. After a few hours of investigation I found the > cause. It is due to a serious bug in the microcode of some 80386's. My machine is also hanged by crash (when I'm using an example from the man page it is subproc. 25, try 3) and it hanged immediately after starting your program. I'm not sure what is the exact processor type although. It is 386DX/20 but it has a radiator over it so I can't see the type description. There is also a coprocessor. We have a similar machine here (bought a month later) and text on the CPU is: "A80386DX-20 L8450327 '85 '86 and two uppercase sigmas. Maybe I'll ask my SysAdm to exchange the CPUs and will see what happens. R. -- Rafal Maszkowski rzm@oso.chalmers.se rzm@mat.uni.torun.pl <-finger for public snail: Omgangen 464-82, 412-80 Goteborg, Sweden; tel: +46-31-7780831 key Opinia publiczna powinna byc zaalarmowana swoim nieistnieniem - St. J. Lec ------------------------------ ** 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 ******************************