home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / os / linux / 10015 < prev    next >
Encoding:
Internet Message Format  |  1992-09-08  |  4.1 KB
  1. Path: sparky!uunet!gatech!bloom-beacon!eru.mt.luth.se!lunic!sunic!news.funet.fi!hydra!klaava!torvalds
  2. From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
  3. Newsgroups: comp.os.linux
  4. Subject: Re: Linux 0.97p2 compatibility, GCC/SHAREDLIBS/JUMPTABLES.
  5. Message-ID: <1992Sep6.185549.8454@klaava.Helsinki.FI>
  6. Date: 6 Sep 92 18:55:49 GMT
  7. References: <k=pnyqq.genie@netcom.com> <BALASUB.92Sep6121304@organ.cis.ohio-state.edu>
  8. Organization: University of Helsinki
  9. Lines: 71
  10.  
  11. In article <BALASUB.92Sep6121304@organ.cis.ohio-state.edu> balasub@organ.cis.ohio-state.edu (Krishna Balasubramanian) writes:
  12. >
  13. >GCC main releases, the corresponding linux version and some
  14. >distributions that use this version of GCC are  approximately 
  15. >as follows: (see the GCC FAQ to find out more).
  16. >
  17. >1) 2.11c, May 19        linux 0.96       x11v1.0 
  18. >2) 2.2.2, Jun 27      > linux 0.96ap4    rootdisk-0.97, x11v1.1, SLS, MCC-0.96c.
  19. >3) 2.2.2d Aug 12      > linux 0.97p1     rootdisk-0.97.1 , MCC-0.97p2
  20. >
  21. >There will probably be a new GCC version with X11 in a week or so.
  22.  
  23. Right.  And in case anybody is nervous about the inverse relation (ie
  24. running old programs under new kernel releases), that should always work
  25. *barring bugs or "undocumented features"*.  So all old binaries will
  26. generally work on new versions of the kernel. 
  27.  
  28. The ptrace() interface was changed in 0.95 - but that was before gdb was
  29. publically available, and it broke no binaries.
  30.  
  31. Other than things like that, all "nice" programs should work from one
  32. release to another.  They may not be able to use new features (VFS etc),
  33. but they should work as well as they ever did.  Note that new gcc
  34. versions, new features etc have made a recompile a good idea, but not
  35. strictly necessary - I still use the following programs:
  36.  
  37.  -rwxr-xr-x   1 torvalds uucp         9491 Aug 19  1991 /bin/sync
  38.  -rwxr-xr-x   1 torvalds uucp        20640 Aug 21  1991 /usr/bin/dhrystone
  39.  -rwxr-xr-x   1 torvalds uucp        72091 Sep  8  1991 /usr/bin/egrep
  40.  -rwxr-xr-x   1 torvalds uucp        72090 Sep  8  1991 /usr/bin/grep
  41.  -rwxr-xr-x   1 torvalds uucp        31176 Sep 13  1991 /usr/bin/od
  42.  
  43. and they work perfectly ok even though some of them are probably from
  44. before the 0.01 release.
  45.  
  46. "non-nice" programs include the 'ps'-suite of programs that muck around
  47. with kernel memory, and simply buggy programs that may work on older
  48. releases. An example of the latter is anything that accesses memory that
  49. it hasn't first allocated with 'brk()'. Those programs worked fine in
  50. 0.96, but 0.96b (I think) adopted the standard unix practice of sending
  51. such a program a SIGSEGV.
  52.  
  53. Similarly, some 'mount' binaries won't work under 0.97.pl2 even though
  54. they worked on pl1.  They did a no-no that just happened to go unchecked
  55. in the older kernel.  Another example of a program that didn't work with
  56. pl2 was "lilo" - it depended on the stat() system call returning the
  57. same buffer-size as used internally in the kernel, which no longer is
  58. necessarily true (and just happened to work in earlier versions). 
  59.  
  60. Of course, there are also kernel bugs that can result in a binary not
  61. working under a new release: this happened in pl2 with the symlink code
  62. and to a lesser extent with /dev/mem.  I generally try to fix that kind
  63. of thing as fast as possible: pl3 has these corrected. 
  64.  
  65. So if you are using an old kernel in the fear that things won't work
  66. with a newer version, you should probably at least try to upgrade: the
  67. chances are everything works fine even if you don't have the latest
  68. user-level binaries.  On the other hand, it may be only prudent to wait
  69. a while until a release has shown itself to be stable - people who are
  70. happy with their current kernel don't necessarily need to upgrade (but
  71. don't be surprised if some new binary doesn't work). 
  72.  
  73.         Linus
  74.  
  75. PS.  None of the above means that future versions of linux will
  76. necessarily be 100% compatible.  If I decide it's worth it, I might
  77. break all old programs by doing something in a more clever way.  But
  78. I'll document it very clearly if I'm aware of the problem.  And it's not
  79. very likely: after all I'm running the same programs as everybody else
  80. (and older versions than some), and I don't feel any terrible urges to
  81. recompile everything. 
  82.