Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!asuvax!noao!ncar!gatech!wrdis01!mips!daver!bungi.com!news From: jkh@meepmeep.pcs.com (Jordan K. Hubbard) Newsgroups: comp.sys.nsc.32k Subject: Yeargh! Estdio is driving me insane! Message-ID: Date: 6 Mar 91 02:34:04 GMT Sender: news@daver.bungi.com Lines: 63 Approved: news@daver.bungi.com 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