Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!mips!sdd.hp.com!uakari.primate.wisc.edu!ames!vsi1!daver!bungi.com!news From: sverre@lev.Seri.GOV (Sverre Froyen) Newsgroups: comp.sys.nsc.32k Subject: Re: Yeargh! Estdio is driving me insane! Message-ID: <9103061513.AA10708@lev.seri.gov> Date: 6 Mar 91 15:13:18 GMT References: <> Sender: news@daver.bungi.com Lines: 84 Approved: news@daver.bungi.com >I am, however, getting rather confused by this rash of estdio patches, >versions, revisions and general mayhem. Sorry about your confusion. I tried to send out a minimal patch. Really, I use a stock estdio with a couple of installation scripts plus a (minimal) set of floating point routines to set up estdio as a _replacement_ for libc. I looked through Jyrki's estdio patches (for Minix 1.3) and, as far as I can tell from a quick browse, they just contain things like site.h, powers.h (incorrect) etc which are generated by yinstall.sh. >My own efforts have been centered around getting estdio to be a >REPLACEMENT for the stdio stuff in libc, and I sort of wish that That was my intention exactly. To get floating point support you need to link in libfp.a in addition. That seems to be a design feature behind estdio and I therefore decided against merging the floating point stuff with libc.a. By the way, contrary to the situation with Minix libc.a and libflt.a, you now get normal vfprintf and friends from libc.a. This allows most gnu utilities to link without the floating point library. >I don't want several versions of stdio.h Just replace /usr/include/stdio.h with the estdio one. When I suggested you save the old one it was only in case you want to back out of estdio. >I use floating point. The PC532 is not an IBM PC and it's a bit silly to be >worrying about an 4K overhead - the floating point should ALWAYS work, >without an extra library. See above. Most programs do not need the floating point (I have removed -lflt from several of my Makefiles). If you really want to merge them my guess is that you can just add (replace?) the libfp routines to libc. >For those of you out there who are new to this entire debate, let >me summarize the difficulties: > >1. Stock estdio 2.1 won't just drop in place inside of libc (I.E. you > can't extract libc.a into a temp directory, extract the compiled > stdio.a on top of it, then repack the whole mess into a new libc.a) > because stdio uses a different internal format. Things like cleanup() in > libc will continue to try and get at structures like _io_table which > exist only in libc, and are now gone. The script ypc532.sh in the INSTALL subdirectory attempts to do just this. It extracts all the routines from libc, replaces several with estdio versions, adds a few new ones, and recreates libc. You just move the new libc.a to /lib/libc.a (or wherever). Notice that the script will recompile certain functions in libc. This is on order to resolve the problems with _io_table etc. It is therefore imperative that you replace /usr/include/stdio.h *before* you run ypc532.sh. See also my instructions in 0_pc532.txt. > >To date, I have not seen anyone (not Jyrki or Sverre) offer a solution >that results in one, clean and neat, solution for a libc.a with floating >point and fast I/O. I thought I had done just what you want (with the exception that you need to include -lfp if you want floating point io. >Should I continue to work on my merge? Please take a second look at my patches. Notice that there were two parts. The first part contained patches for estdio and the second part contained a new libfp. I do agree with you that having multiple versions of estdio out there is *not* a good thing and that we should try to settle on one official set of patches. >If I am wrong, can someone correct me with enough detail (assume that >I'm very very stupid - it never hurts! :-) that I can follow in your >footsteps? The file 0_pc532.txt contains step by step instructions to get estdio compiled and installed as a replacement for libc.a. The only problem I can think of is that the installation script ypc532.sh possibly assumes that libc and its sources are in specific directories, but that should be easy to fix :-). Keep me posted. --Sverre