AJB@dlvh.daresbury.ac.uk (07/05/90)
1. LIBORDERS Recent discussions on liborders seems to have neglected a fundamental problem which maybe someone out there has addressed(?) I'm a 2Mb STE owner who therefore has RANLIB capability but that does NOT help in the construction of a 'truly up-to-date' libc.a so PC and ST(x) owners are in the same quandary regarding the following scenario. My conceptual problem is basically this: When you're upgrading Minix you recompile OTHER/ANSI/POSIX etc using your current libc.a Changes in the source libraries are therefore compiled using the 'old' libc.a and therefore incorporate machine code from that library. Now, this is inconsequential if independent routines are compiled (there are workarounds). But what happens if changes are made between updates to mutually dependent routines in the library? Multiple compilations with temporary libraries seems the only sure way to get a 'current' library. 2. REBOOTS This problem is ST-related. When I first started using Minix on an ST and wanted to logout I dutifully dismounted all devices and processes, CTRL-D'd and pressed RESET (or CTRL_ALT_(RIGHT_SHIFT)-DEL'd on TOS1.4) on my 1040ST. All I got was a black screen and, after 5 seconds, a high- pitched whine from the monitor; the only escape was a powerdown. I recently got a 2Mb STE, rebuilt Minix on my hard drive and could happily return to TOS using either RESET or any CTRL-ALT-DEL combination (after dismounting properly etc etc). I then decided to increase the size of the RAMDISC by re-MKFSing /dev/hd3 (my RFS) and loading the RFS back onto it. MINIX still works fine but whenever I try to return to the desktop using either route all I get is the 5 second pause, high pitched whine and the need to turn off my machine :-( Any solutions? 3. MUNDANE The only ST 1.5.10 file I haven't got the correct CRC for is commands/stterm/term.c I'D BE VERY GRATEFUL IF SOME KIND SOUL WOULD MAIL ME A COPY!!!! :-) Alan Bleasby
paula@bcsaic.UUCP (Paul Allen) (07/06/90)
I'm following-up rather than mailing because there may be others who share this misunderstanding about rebuilding libc.a. (Please note that it's OK to misunderstand! Sometimes my life seems to be one big misunderstanding, but we won't go into that... :-) ) In article <23637@nigel.udel.EDU> AJB@dlvh.daresbury.ac.uk writes: > My conceptual problem is basically this: > When you're upgrading Minix you recompile OTHER/ANSI/POSIX etc using > your current libc.a > Changes in the source libraries are therefore compiled using the 'old' > libc.a and therefore incorporate machine code from that library. What's missing here is the fact that libc.a is only used at link time. When you compile the library sources you're only making new object files, not new executables. Unless you keep old library object files around, it's not possible for a new libc.a to be contaminated by traces of any previous one. Paul Allen -- ------------------------------------------------------------------------ Paul L. Allen | pallen@atc.boeing.com Boeing Advanced Technology Center | ...!uw-beaver!bcsaic!pallen
eesrajm@cc.brunel.ac.uk (Andrew J Michael) (07/07/90)
In article <23637@nigel.udel.EDU>, AJB@dlvh.daresbury.ac.uk writes: > 1. LIBORDERS > Recent discussions on liborders seems to have neglected a fundamental > problem which maybe someone out there has addressed(?) > I'm a 2Mb STE owner who therefore has RANLIB capability but that does > NOT help in the construction of a 'truly up-to-date' libc.a so PC > and ST(x) owners are in the same quandary regarding the following > scenario. > > My conceptual problem is basically this: > When you're upgrading Minix you recompile OTHER/ANSI/POSIX etc using > your current libc.a > Changes in the source libraries are therefore compiled using the 'old' > libc.a and therefore incorporate machine code from that library. Umm - No. The contents of your current libc.a are irrelevant until you try to link something with it. You don't link anything when building the library sources, so libc.a doesn't affect the library sources at all. However, I am bemused at recent comments that library orders seem to be different for different people. If we are using the same sources and Makefiles, how can the library order be non-deterministic ? Comments anyone ? Andy Michael -- Andy Michael (eesrajm@cc.brunel.ac.uk) " Software cannot be written to 85 Hawthorne Crescent be completely free of errors." West Drayton Middlesex - Acorn Computers Ltd. UB7 9PA
cagney@chook.ua.oz (Andrew Cagney - aka Noid) (07/08/90)
From article <1725@Terra.cc.brunel.ac.uk>, by eesrajm@cc.brunel.ac.uk (Andrew J > > However, I am bemused at recent comments that library orders seem to be > different for different people. If we are using the same sources and > Makefiles, how can the library order be non-deterministic ? > > Comments anyone ? I beleive your correct, the process is deterministic, however there is always that wonderful phrase: `for any given input' :-) Depending on which way you initially build an unordered library you could end up with a slightly different ordered final library. For instance you could build your initial library using: ar r draftc.a string/*.s ar r draftc.a ansi/*.s alternativly you could use ar r ansi/*.s ar r string/*.s which would change the initial library order: => changes the output from lorder => tsort would create its graph in a different order => tsort outputs a slightly different final list Am I correct? Andrew Cagney Sorry about the below: Barron `Wim' your address ``tgcpwd@eutrc3.urc.tue.nl'' just bounced :-( with lots of: Received: from tuegate.tue.nl by rc6.urc.tue.nl with SMTP id AA06760 (5.64+/IDA-1.3.1 for tgcpwd@eutrc3.urc.tue.nl); Sun, 8 Jul 90 06:17:49 +0200 Received: by tuegate.tue.nl (5.57/1.35) id AA04149; Sun, 8 Jul 90 06:14:57 +0200 But it took about 2 minutes to go from oz to nl and back :-)
HBO043%DJUKFA11.BITNET@cunyvm.cuny.edu (Christoph van Wuellen) (07/11/90)
The whole liborder discussion reveals nothing but the deficiencies of the MINIX-PC asld/library concept. Go on and include ranlib in MINIX/PC for bandwidth's sake! C.v.W.
HBO043%DJUKFA11.BITNET@cunyvm.cuny.edu (Christoph van Wuellen) (07/11/90)
(about non-deterministic liborder) Oh, well. When constructing a new library from scratch, be sure to do rm /usr/lib/libc.a first! C.v.W.
ast@cs.vu.nl (Andy Tanenbaum) (07/14/90)
In article <24216@nigel.udel.EDU> HBO043%DJUKFA11.BITNET@cunyvm.cuny.edu (Christoph van Wuellen) writes: >The whole liborder discussion reveals nothing but the deficiencies of >the MINIX-PC asld/library concept. I agree. The MINIX ANSI compiler, which is being beta-tested now, has a ranlib mechanism built into the linker (which is separate from the assembler, as in MINIX-ST). Andy Tanenbaum (ast@cs.vu.nl)
HBO043%DJUKFA11.BITNET@cunyvm.cuny.edu (Christoph van Wuellen) (07/16/90)
Will the assembler support long external names? This is one of the things I hate most on my 68K MINIX system. We have sources of the compiler, linker etc. But the assembler is binary-only. And global names where only the first seven characters (due to the underscore) ar valid are somehow outdated. 68K MINIX offers the capability to port high-quality software to it because of the ,,unlimited'' address space. The restriction on external names destroys this sometimes. C.v.W.