jkh@meepmeep.pcs.com (Jordan K. Hubbard) (03/06/91)
Ok. So maybe I'm a little hypersensitive.. I am, however, getting rather confused by this rash of estdio patches, versions, revisions and general mayhem. I have devoted several sleepless nights to getting this all working and am getting somewhat confused. 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 other folks were heading in the same direction. I don't want to compile with -DESTDIO and link with -lstdio, I don't want some arcane combination of -lflt, -lstdiofp and -lstdio, I don't want several versions of stdio.h What I want is one simple version of /lib/libc.a and /usr/include/stdio.h that will get me the best possible performance and not hose me when 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. Don't mean to sound like I'm bitching here, I just want to know if anyone else shares these simple goals or if I should still keep spending time doing all this independently. 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. 2. You can't just copy estdio into /lib/libstdio.a and expect to be able to link with -lstdio ahead of libc (assuming that you've also replaced stdio.h with the estdio one), because certain calls like popen() will still "fall through" estdio and hit libc.a, running into the same sorts of problems with internal incompatability in FILE formats (you'll also now have duplicate global stderr, stdout and stdin symbols - a no-no). 3. You can't simply copy over those "missing routines" (like popen() or cleanup()) from libc and adapt them to stdio, compiling them all as part of libstdio.a, because you will now run into problems with FLOATING POINT! Yea! Our favorite. The ways that vfscanf() and vfprintf() handle floating point in the two libraries are very different, and not all that easy to merge. estdio itself has no support for floating point, you being expected to import missing bits from elsewhere. 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. Am I the only one that likes things neat? Should I continue to work on my merge? 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? Jordan
jkp@sauna.hut.fi (Jyrki Kuoppala) (03/06/91)
In article <m0jDeUk-0003MvC@meepmeep.pcs.com> Jordan writes: >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. Well, I use libc.a which has all the stdio routines from estdio, others from Minix libc.a. Then there's ldexp.s and frexp.s from the Mach group here. No trouble, except that fdopen() or freopen() doesn't seem to work properly (but that problem was even with the original Minix libc.a). I haven't looked into that yet. Floating point works fine, except the bug in estdio that was mentioned - it sometimes prints ':'-characters, gcc 1.39 cc1 exhibits this problem. The -DESTDIO you mention is mostly only for user programs to conditionalize their own kludgein over stdio's internal data structures which they of course shouldn't be doing anyway. >Am I the only one that likes things neat? > >Should I continue to work on my merge? I have a merge, although it isn't that much tested - if you test it or make a better one, feel free. I only took stdio.a and stdiofp.a from estdio, the Mach group's ldexp & frexp, modf * norm & atof & strtod from libflt and the rest from Minix libc.a compiled with estdio's stdio.h, of course. Works fine except for the few trouble points listed above. //Jyrki
sverre@lev.Seri.GOV (Sverre Froyen) (03/06/91)
>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
culberts@hplwbc.hpl.hp.com (Bruce Culbertson) (03/07/91)
My two cents worth... I am basically in agreement with Jordan on stdio/estdio. No one wants to keep choosing between two stdio's on a daily basis. I could see having a small stdio available for compiling a few of the most fundamental /bin commands -- cp, cat, mkdir, etc. That way you could make a really small emergency file system. But once that was done (if it is even that important), I personally would never use the small stdio again. Someone else, though, might always want to use the small stdio. It would be nice if we had simple, fool-proof, scripts for installing each. But I do not think it's necessary that the two stdio's be able to co-exist, each equally accessible on the same file system. > (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) I still am not clear why this doesn't work. Do some commands and non-stdio library routines make assumptions about data that should really be private to stdio? Do they call routines which should really be private to stdio? Maybe we could cajole the original authors of estdio to clean this up. If we fix it ourselves, then it will be hard to merge updates into our sources. Bruce
sverre@lev.Seri.GOV (Sverre Froyen) (03/07/91)
> >Well, I use libc.a which has all the stdio routines from estdio, >others from Minix libc.a. Then there's ldexp.s and frexp.s from the >Mach group here. No trouble, except that fdopen() or freopen() >doesn't seem to work properly (but that problem was even with the >original Minix libc.a). I haven't looked into that yet. Floating What is the problem with fdopen? The only problem I noticed was that errno would be set to ENOTTY because of a bug (now fixed) in isatty. >I have a merge, although it isn't that much tested - if you test it or >make a better one, feel free. I only took stdio.a and stdiofp.a from >estdio, the Mach group's ldexp & frexp, modf * norm & atof & strtod >from libflt and the rest from Minix libc.a compiled with estdio's The strtod from libflt is off (roundoff) by a couple of bits compared to (the correct) scanf from estdio. I borrowed strtod from libfp and wrote a couple of support routines that I believe give good results. I sent those out as libfp a couple of days ago. Notice that you should reload Bruce's as and also gcc with the new version. -- Sverre Froyen sverre@seri.gov, sunpeaks!seri!sverre
jkp@sauna.hut.fi (Jyrki Kuoppala) (03/10/91)
>What is the problem with fdopen? The only problem I noticed >was that errno would be set to ENOTTY because of a bug (now fixed) >in isatty. I have applied the isatty patch, but compress still doesn't seem to work with more than one file. I jumped into a conclusion that the bug is in freopen / fdopen because also GNU tail fails reading from stdin, but I haven't debugged it. Later I found out that the GNU tail problem appears to be fstat() return erraneous information for pipes. So it might be a related or unrelated bug which makes compress fail, not necessarily because of estdio. >The strtod from libflt is off (roundoff) by a couple of bits >compared to (the correct) scanf from estdio. I borrowed >strtod from libfp and wrote a couple of support routines >that I believe give good results. I sent those out as libfp >a couple of days ago. Notice that you should reload Bruce's as >and also gcc with the new version. OK, now I'm using your libfp, with ldexp and frexp replaced with the assembler versions by the Mach group. Any cure yet to the problem of gcc printing ':'-characters ? Is the bug in estdio or modf ? //Jyrki