Another libio patch

Another libio patch

[H.J. Lu]

Hi,

Please discard my previous libio patch. This patch should
fix both glibc 2 and libc 5. Please let me know the result
on libc 5.3.12 on linux/x86.

Thanks.


-- 
H.J. Lu (hjl@gnu.ai.mit.edu)
---
Thu Oct  9 07:08:41 1997  H.J. Lu  (hjl@gnu.ai.mit.edu)

	* libio.h (_IO_LOCK_T): Handle glibc 2 when _IO_MTSAFE_IO is
	not defined.

	* filedoalloc.c (_IO_file_doallocate): Don't call
	_IO_cleanup_registration_needed if __linux__ is defined.

	* iofclose.c (fclose): Make it weak alias of _IO_fclose if
	__ELF__ is defined.

	* iovsprintf.c (vsprintf): Make it weak alias of _IO_vsprintf
	if __ELF__ is defined.

	* iovsscanf.c (vsscanf): Make it weak alias of _IO_vsscanf if
	__ELF__ is defined.

	* config/linuxlibc1.mt (MT_CFLAGS): Defined as -D_G_HAVE_MMAP.
	(IO_OBJECTS): Add filedoalloc.o fileops.o genops.o iofclose.o
	iovsprintf.o iovsscanf.o strops.o.

Index: libio/filedoalloc.c
===================================================================
RCS file: /home/work/cvs/gnu/egcs/libio/filedoalloc.c,v
retrieving revision 1.1.1.2
diff -u -r1.1.1.2 filedoalloc.c
--- filedoalloc.c	1997/09/08 01:01:01	1.1.1.2
+++ filedoalloc.c	1997/10/09 19:47:37
@@ -75,7 +75,7 @@
   char *p;
   struct stat st;
 
-#ifndef _LIBC
+#if !defined(_LIBC) && !defined(__linux__)
   /* If _IO_cleanup_registration_needed is non-zero, we should call the
      function it points to.  This is to make sure _IO_cleanup gets called
      on exit.  We call it from _IO_file_doallocate, since that is likely
Index: libio/iofclose.c
===================================================================
RCS file: /home/work/cvs/gnu/egcs/libio/iofclose.c,v
retrieving revision 1.1.1.2
diff -u -r1.1.1.2 iofclose.c
--- iofclose.c	1997/09/08 01:01:02	1.1.1.2
+++ iofclose.c	1997/10/09 19:02:33
@@ -55,4 +55,8 @@
 
 #ifdef weak_alias
 weak_alias (_IO_fclose, fclose)
+#else
+#ifdef __ELF__
+#pragma weak fclose = _IO_fclose
+#endif
 #endif
Index: libio/iovsprintf.c
===================================================================
RCS file: /home/work/cvs/gnu/egcs/libio/iovsprintf.c,v
retrieving revision 1.1.1.2
diff -u -r1.1.1.2 iovsprintf.c
--- iovsprintf.c	1997/09/08 01:01:05	1.1.1.2
+++ iovsprintf.c	1997/10/09 19:03:52
@@ -54,4 +54,8 @@
 
 #ifdef weak_alias
 weak_alias (_IO_vsprintf, vsprintf)
+#else
+#ifdef __ELF__
+#pragma weak vsprintf = _IO_vsprintf
+#endif
 #endif
Index: libio/iovsscanf.c
===================================================================
RCS file: /home/work/cvs/gnu/egcs/libio/iovsscanf.c,v
retrieving revision 1.1.1.2
diff -u -r1.1.1.2 iovsscanf.c
--- iovsscanf.c	1997/09/08 01:01:05	1.1.1.2
+++ iovsscanf.c	1997/10/09 19:03:29
@@ -51,4 +51,8 @@
 #ifdef weak_alias
 weak_alias (_IO_vsscanf, __vsscanf)
 weak_alias (_IO_vsscanf, vsscanf)
+#else
+#ifdef __ELF__
+#pragma weak vsscanf = _IO_vsscanf
+#endif
 #endif
Index: libio/libio.h
===================================================================
RCS file: /home/work/cvs/gnu/egcs/libio/libio.h,v
retrieving revision 1.1.1.6
diff -u -r1.1.1.6 libio.h
--- libio.h	1997/10/09 17:31:37	1.1.1.6
+++ libio.h	1997/10/10 21:53:01
@@ -157,15 +157,17 @@
 # endif
 #else
 /* XXX This will go away as soon as comthread is finished.  */
-# ifdef __linux__
+# if defined __GLIBC__ && __GLIBC__ >= 2
+#  define _IO_LOCK_T void *
+# else
+#  ifdef __linux__
 struct _IO_lock_t {
   void *ptr;
   short int field1;
   short int field2;
 };
-#  define _IO_LOCK_T struct _IO_lock_t
-# else
-typedef void _IO_lock_t;
+#   define _IO_LOCK_T struct _IO_lock_t
+#  endif
 # endif
 #endif
 
Index: libio/config/linuxlibc1.mt
===================================================================
RCS file: /home/work/cvs/gnu/egcs/libio/config/linuxlibc1.mt,v
retrieving revision 1.1.1.3
diff -u -r1.1.1.3 linuxlibc1.mt
--- linuxlibc1.mt	1997/10/09 17:31:39	1.1.1.3
+++ linuxlibc1.mt	1997/10/09 19:38:44
@@ -9,7 +9,9 @@
 LIBIO_INCLUDE=
 
 # We have those in libc.a.
-IO_OBJECTS=iogetc.o ioputc.o iofeof.o ioferror.o
+IO_OBJECTS=iogetc.o ioputc.o iofeof.o ioferror.o \
+	filedoalloc.o fileops.o genops.o iofclose.o \
+	iovsprintf.o iovsscanf.o strops.o
 STDIO_WRAP_OBJECTS=
 OSPRIM_OBJECTS=
 STDIO_OBJECTS=
@@ -19,3 +21,6 @@
 	indstream.h iomanip.h iostream.h istream.h ostream.h \
 	parsestream.h pfstream.h procbuf.h stdiostream.h stream.h \
 	streambuf.h strfile.h strstream.h
+
+# A bad kludge
+MT_CFLAGS=-D_G_HAVE_MMAP

Re: Another libio patch

[Ulrich Drepper]

hjl@lucon.org (H.J. Lu) writes:

> Please discard my previous libio patch. This patch should
> fix both glibc 2 and libc 5. Please let me know the result
> on libc 5.3.12 on linux/x86.

This looks much better.  Though

>  #ifdef weak_alias
>  weak_alias (_IO_vsprintf, vsprintf)
> +#else
> +#ifdef __ELF__
> +#pragma weak vsprintf = _IO_vsprintf
> +#endif
>  #endif

I don't think we should use the alias for other ELF systems (Solaris etc).
I think this should read

	#if defined __linux__ && defined __ELF__

-- Uli
---------------.      drepper@cygnus.com  ,-.   Rubensstrasse 5
Ulrich Drepper  \    ,-------------------'   \  76149 Karlsruhe/Germany
Cygnus Solutions `--' drepper@gnu.ai.mit.edu  `------------------------

Re: Another libio patch

[H.J. Lu]

> 
> hjl@lucon.org (H.J. Lu) writes:
> 
> > Please discard my previous libio patch. This patch should
> > fix both glibc 2 and libc 5. Please let me know the result
> > on libc 5.3.12 on linux/x86.
> 
> This looks much better.  Though
> 
> >  #ifdef weak_alias
> >  weak_alias (_IO_vsprintf, vsprintf)
> > +#else
> > +#ifdef __ELF__
> > +#pragma weak vsprintf = _IO_vsprintf
> > +#endif
> >  #endif
> 
> I don't think we should use the alias for other ELF systems (Solaris etc).
> I think this should read
> 
> 	#if defined __linux__ && defined __ELF__
> 

That is fine.

Thanks.


H.J.

HJ's patch to libio works on Red Hat 4.2/libc 5.3.12

[Joe Buck]

HJ wrote:
> > > Please discard my previous libio patch. This patch should
> > > fix both glibc 2 and libc 5. Please let me know the result
> > > on libc 5.3.12 on linux/x86.

Ulrich suggested changing __ELF__ to
> > 	#if defined __linux__ && defined __ELF__

I installed HJ's patch, as modified according to Ulrich's suggestion,
and all libio tests pass on a straight Red Hat 4.2 system.

Congratulations, HJ!  To be more thorough we should try more cases,
but I feel *much* better now about egcs on Linux and its accessibility
to non-hackers, if anyone with a relatively standard system only
has to download, configure, make bootstrap-lean, make install to
get going from source, and doesn't have to find and install other
packages.

I think this is good enough to satisfy my main concern.  I don't feel
that similar efforts to support older glibc setups are anywhere near
as important, though the "completely separate libio" option is still
a possibility.

Joe

Re: HJ's patch to libio works on Red Hat 4.2/libc 5.3.12

[H.J. Lu]

> 
> I installed HJ's patch, as modified according to Ulrich's suggestion,
> and all libio tests pass on a straight Red Hat 4.2 system.

Glad to hear that.

> as important, though the "completely separate libio" option is still
> a possibility.

I don't like to see it. As pointed out by Ulrich, many optimizations
and operations can only be done with libio in libc. But on the
other hand, I don't mind to see egcs with glibc.


-- 
H.J. Lu (hjl@gnu.ai.mit.edu)

Re: HJ's patch to libio works on Red Hat 4.2/libc 5.3.12

[Mumit Khan]

Joe Buck <jbuck@synopsys.com> writes:
> I installed HJ's patch, as modified according to Ulrich's suggestion,
> and all libio tests pass on a straight Red Hat 4.2 system.

Same here.

I seem to have an additional problem however. The attched stripped
down code core dumps on a i386-linux-gnulibc1 box with libc 5.3.12 
(RH 4.2). I've also attched the backtrace from gdb.

I've applied Jason's and HLJ's patches to date to egcs-971008.

To run it, create a text file "data.in" with a floating point number in
it.

=====
#include <fstream.h>
#include <cstdlib>

int main () {
  ifstream ifp ("data.in");
  if (!ifp) {
    cerr << "Error opening input \"data.in\"" << endl;
    exit (1);
  }

  double dummy;
  ifp >> dummy;			// <<<<<<< CORE DUMPS HERE
  if (!ifp) {
    cerr << "Error reading input \"data.in\"" << endl;
    exit (1);
  }

  exit (1);
}
=====

Here's the back trace:

% c++  -g -o ifstream ifstream.cc
% gdb ifstream
GDB is free software and you are welcome to distribute copies of it
 under certain conditions; type "show copying" to see the conditions.
There is absolutely no warranty for GDB; type "show warranty" for details.
GDB 4.16 (i586-unknown-linux), Copyright 1996 Free Software Foundation,
Inc...
(gdb) r
Starting program: /tmp/ifstream 
warning: Unable to find dynamic linker breakpoint function.
warning: GDB will be unable to debug shared library initializers
warning: and track explicitly loaded dynamic code.

Program received signal SIGSEGV, Segmentation fault.
0x4002dc12 in ostream::flush (this=0x40030bfc)
    at ../../../libio/iostream.cc:854
854         if (_strbuf->sync())
(gdb) bt
#0  0x4002dc12 in ostream::flush (this=0x40030bfc)
    at ../../../libio/iostream.cc:854
#1  0x4002ccd3 in istream::operator>> (this=0xbffffa28, x=@0xbffff9cc)
    at ../../../libio/iostream.h:159
#2  0x8048ae0 in main () at ifstream.cc:12
#3  0x80489db in ___crt_dummy__ ()
#4  0x4002b2f8 in __tf8ifstream () at ../../../libio/fstream.h:61
Cannot access memory at address 0xffa0.
(gdb) 

Re: HJ's patch to libio works on Red Hat 4.2/libc 5.3.12

[H.J. Lu]

> 
> Joe Buck <jbuck@synopsys.com> writes:
> > I installed HJ's patch, as modified according to Ulrich's suggestion,
> > and all libio tests pass on a straight Red Hat 4.2 system.
> 
> Same here.
> 
> I seem to have an additional problem however. The attched stripped
> down code core dumps on a i386-linux-gnulibc1 box with libc 5.3.12 
> (RH 4.2). I've also attched the backtrace from gdb.
> 
> I've applied Jason's and HLJ's patches to date to egcs-971008.
> 
> To run it, create a text file "data.in" with a floating point number in
> it.
> 
> =====
> #include <fstream.h>
> #include <cstdlib>
> 
> int main () {
>   ifstream ifp ("data.in");
>   if (!ifp) {
>     cerr << "Error opening input \"data.in\"" << endl;
>     exit (1);
>   }
> 
>   double dummy;
>   ifp >> dummy;			// <<<<<<< CORE DUMPS HERE
>   if (!ifp) {
>     cerr << "Error reading input \"data.in\"" << endl;
>     exit (1);
>   }
> 
>   exit (1);
> }
> =====
> 
> Here's the back trace:
> 
> % c++  -g -o ifstream ifstream.cc
> % gdb ifstream
> GDB is free software and you are welcome to distribute copies of it
>  under certain conditions; type "show copying" to see the conditions.
> There is absolutely no warranty for GDB; type "show warranty" for details.
> GDB 4.16 (i586-unknown-linux), Copyright 1996 Free Software Foundation,
> Inc...
> (gdb) r
> Starting program: /tmp/ifstream 
> warning: Unable to find dynamic linker breakpoint function.
> warning: GDB will be unable to debug shared library initializers
> warning: and track explicitly loaded dynamic code.
> 
> Program received signal SIGSEGV, Segmentation fault.
> 0x4002dc12 in ostream::flush (this=0x40030bfc)
>     at ../../../libio/iostream.cc:854
> 854         if (_strbuf->sync())
> (gdb) bt
> #0  0x4002dc12 in ostream::flush (this=0x40030bfc)
>     at ../../../libio/iostream.cc:854
> #1  0x4002ccd3 in istream::operator>> (this=0xbffffa28, x=@0xbffff9cc)
>     at ../../../libio/iostream.h:159
> #2  0x8048ae0 in main () at ifstream.cc:12
> #3  0x80489db in ___crt_dummy__ ()
> #4  0x4002b2f8 in __tf8ifstream () at ../../../libio/fstream.h:61
> Cannot access memory at address 0xffa0.
> (gdb) 
> 
> 

I think somehow your libstdc++ is miscompiled.

-- 
H.J. Lu (hjl@gnu.ai.mit.edu)

Re: HJ's patch to libio works on Red Hat 4.2/libc 5.3.12

[Joe Buck]

> > I seem to have an additional problem however. The attched stripped
> > down code core dumps on a i386-linux-gnulibc1 box with libc 5.3.12 
> > (RH 4.2). I've also attched the backtrace from gdb.

HJ:
> I think somehow your libstdc++ is miscompiled.

I get the exact same failure.  Just in case there was a compilation
problem, I blew away and recompiled the libraries.  The crash is still
there.

Joe

Re: HJ's patch to libio works on Red Hat 4.2/libc 5.3.12

[Mumit Khan]

Joe Buck <jbuck@synopsys.com> writes:
> HJ:
> > I think somehow your libstdc++ is miscompiled.
> 
> I get the exact same failure.  Just in case there was a compilation
> problem, I blew away and recompiled the libraries.  The crash is still
> there.
> 

Not once, but twice ;-) The 3rd time was with Richard Henderson's patch 
posted on the 11th (which contains HJL's patches as well), but had same 
results.

Mumit

Re: HJ's patch to libio works on Red Hat 4.2/libc 5.3.12

[H.J. Lu]

> 
> 
> > > I seem to have an additional problem however. The attched stripped
> > > down code core dumps on a i386-linux-gnulibc1 box with libc 5.3.12 
> > > (RH 4.2). I've also attched the backtrace from gdb.
> 
> HJ:
> > I think somehow your libstdc++ is miscompiled.
> 
> I get the exact same failure.  Just in case there was a compilation
> problem, I blew away and recompiled the libraries.  The crash is still
> there.
> 

The example works fine on my machine. From the gdb back strace, it
looks like there is some mismatch since the code should not even
be reached.

If someone can send the complete gdb step through of
istream& istream::operator>>(double& x), I will take 
another look.


-- 
H.J. Lu (hjl@gnu.ai.mit.edu)

Re: HJ's patch to libio works on Red Hat 4.2/libc 5.3.12

[Mumit Khan]

hjl@lucon.org (H.J. Lu) writes:
> 
> The example works fine on my machine. From the gdb back strace, it
> looks like there is some mismatch since the code should not even
> be reached.
> 
> If someone can send the complete gdb step through of
> istream& istream::operator>>(double& x), I will take 
> another look.
> 

Think I know what the problem is now. The following files are not 
installed by default now in $prefix/include/g++:
    
    libio.h
    libioP.h
    iostreamP.h
    iostdio.h
    iolibio.h
    floatio.h

I had these files leftover from Sept 24 snapshot, and weren't overwritten
during subsequent snapshot installs. Once I installed these by hand from
current egcs/libio, my simple testcase worked as expected. The reason
that the libio testsuite worked is because it uses -nostdinc++ and then
explicitly includes the libio source in the include path, hence not
looking at the bad copy in the installation tree.

Regards,
Mumit

Re: HJ's patch to libio works on Red Hat 4.2/libc 5.3.12

[Joe Buck]

Mumit writes:

> Think I know what the problem is now. The following files are not 
> installed by default now in $prefix/include/g++:
>     
>     libio.h
>     libioP.h
>     iostreamP.h
>     iostdio.h
>     iolibio.h
>     floatio.h
> 
> I had these files leftover from Sept 24 snapshot, and weren't overwritten
> during subsequent snapshot installs.

Thanks for tracking this down, Mumit.

libg++ has suffered from similar problems for many years: failures due
to leftover files from previous versions (e.g. _G_config.h, etc).  Several
items in the g++ FAQ deal with this.

Perhaps "make install" should be fixed to remove everything in
$prefix/include/g++ before installing the new headers (and of course
we should warn folks that this is going to happen).

Joe

Re: HJ's patch to libio works on Red Hat 4.2/libc 5.3.12

[H.J. Lu]

> 
> hjl@lucon.org (H.J. Lu) writes:
> > 
> > The example works fine on my machine. From the gdb back strace, it
> > looks like there is some mismatch since the code should not even
> > be reached.
> > 
> > If someone can send the complete gdb step through of
> > istream& istream::operator>>(double& x), I will take 
> > another look.
> > 
> 
> Think I know what the problem is now. The following files are not 
> installed by default now in $prefix/include/g++:
>     
>     libio.h
>     libioP.h
>     iostreamP.h
>     iostdio.h
>     iolibio.h
>     floatio.h
> 
> I had these files leftover from Sept 24 snapshot, and weren't overwritten
> during subsequent snapshot installs. Once I installed these by hand from

Have you tried to remove them, except for libio.h? You should
also remove _G_config.h installed by egcs.


-- 
H.J. Lu (hjl@gnu.ai.mit.edu)

Re: Another libio patch

[Neal Becker]

What needs to be done so that -lpthread is not needed on linux/glibc2?
 I have applied the patch to /usr/include/libc-lock.h.  Rebuilding
libstdc++ doesn't fix it - libstdc++.so still references two symbols
defined in pthread.  Do I need to rebuild glibc?

Re: Another libio patch

[H.J. Lu]

> 
> What needs to be done so that -lpthread is not needed on linux/glibc2?
>  I have applied the patch to /usr/include/libc-lock.h.  Rebuilding
> libstdc++ doesn't fix it - libstdc++.so still references two symbols
> defined in pthread.  Do I need to rebuild glibc?
> 

That should not happen. With my patch, those 2 symbols should
be weak and ld won't complain.

-- 
H.J. Lu (hjl@gnu.ai.mit.edu)

Another libio patch

[H.J. Lu]

Here is another libio patch.

-- 
H.J. Lu (hjl@gnu.ai.mit.edu)
---
Mon Nov 17 08:39:17 1997  H.J. Lu  (hjl@gnu.ai.mit.edu)

	* stdstrbufs.cc (DEF_STDFILE): Use STD_VTABLE.

Index: stdstrbufs.cc
===================================================================
RCS file: /home/work/cvs/gnu/egcs/libio/stdstrbufs.cc,v
retrieving revision 1.1.1.2
diff -u -r1.1.1.2 stdstrbufs.cc
--- stdstrbufs.cc	1997/09/17 20:12:34	1.1.1.2
+++ stdstrbufs.cc	1997/11/17 20:38:04
@@ -58,7 +58,7 @@
 #define DEF_STDFILE(NAME, FD, CHAIN, FLAGS) \
   static _IO_lock_t _IO_stdfile_##FD##_lock = _IO_lock_initializer; \
   struct _IO_FILE_plus NAME \
-    = {FILEBUF_LITERAL(CHAIN, FLAGS, FD), &_IO_file_jumps}
+    = {FILEBUF_LITERAL(CHAIN, FLAGS, FD), STD_VTABLE}
 #else
 #define DEF_STDFILE(NAME, FD, CHAIN, FLAGS) \
   struct _IO_FILE_plus NAME = {FILEBUF_LITERAL(CHAIN, FLAGS, FD), STD_VTABLE}

Re: Another libio patch

[Jeffrey A Law]

  In message < m0xXY3s-0004ecC@ocean.lucon.org >you write:
  > Here is another libio patch.
  > 
  > -- 
  > H.J. Lu (hjl@gnu.ai.mit.edu)
  > ---
  > Mon Nov 17 08:39:17 1997  H.J. Lu  (hjl@gnu.ai.mit.edu)
  > 
  > 	* stdstrbufs.cc (DEF_STDFILE): Use STD_VTABLE.
I have no idea what this patch does since you didn't make any attempt to
describe the problem it's trying to fix.  I will not install it unless I
hear from Ulrich.

Ulrich -- is this patch correct?

  > 
  > Index: stdstrbufs.cc
  > ===================================================================
  > RCS file: /home/work/cvs/gnu/egcs/libio/stdstrbufs.cc,v
  > retrieving revision 1.1.1.2
  > diff -u -r1.1.1.2 stdstrbufs.cc
  > --- stdstrbufs.cc	1997/09/17 20:12:34	1.1.1.2
  > +++ stdstrbufs.cc	1997/11/17 20:38:04
  > @@ -58,7 +58,7 @@
  >  #define DEF_STDFILE(NAME, FD, CHAIN, FLAGS) \
  >    static _IO_lock_t _IO_stdfile_##FD##_lock = _IO_lock_initializer; \
  >    struct _IO_FILE_plus NAME \
  > -    = {FILEBUF_LITERAL(CHAIN, FLAGS, FD), &_IO_file_jumps}
  > +    = {FILEBUF_LITERAL(CHAIN, FLAGS, FD), STD_VTABLE}
  >  #else
  >  #define DEF_STDFILE(NAME, FD, CHAIN, FLAGS) \
  >    struct _IO_FILE_plus NAME = {FILEBUF_LITERAL(CHAIN, FLAGS, FD), STD_VTAB
  > LE}

Re: Another libio patch

[H.J. Lu]

> 
> 
>   In message < m0xXY3s-0004ecC@ocean.lucon.org >you write:
>   > Here is another libio patch.
>   > 
>   > -- 
>   > H.J. Lu (hjl@gnu.ai.mit.edu)
>   > ---
>   > Mon Nov 17 08:39:17 1997  H.J. Lu  (hjl@gnu.ai.mit.edu)
>   > 
>   > 	* stdstrbufs.cc (DEF_STDFILE): Use STD_VTABLE.
> I have no idea what this patch does since you didn't make any attempt to
> describe the problem it's trying to fix.  I will not install it unless I

iostream should the C++ vtable. You can see STD_VTABLE is
used for another case in the same file.

> hear from Ulrich.
> 
> Ulrich -- is this patch correct?

That is one of the many problems with glibc 2 and egcs. The newer
glibc 2.1 breaks egcs due to the changes to libio in glibc 2.1.
I'd like to see glibc 2.1 install those libio private header files
and libio in egcs uses them if they are available. We may be
able to support libc 5, glibc 2.0 and glibc 2.1 in egcs.

H.J.

Another libio patch

[H.J. Lu]

I forgot this one in my libio patch.

Sorry for that.

-- 
H.J. Lu (hjl@gnu.ai.mit.edu)
--
--- /dev/null	Wed Dec 31 16:00:00 1969
+++ libio/config/libio.mt	Mon Aug 25 18:42:20 1997
@@ -0,0 +1,13 @@
+# Used by systems which implement stdio upon libio.
+# If libio in libc is not compatible with thunks, we
+# have to compile a few things ourselves.
+# FIXME: Use vfprintf.c and vfscanf.c from glibc.
+IO_OBJECTS=filedoalloc.o floatconv.o genops.o fileops.o iovfprintf.o \
+	   iovfscanf.o iopadn.o ioseekoff.o ioseekpos.o outfloat.o \
+	   strops.o iofclose.o iopopen.o \
+	   iofdopen.o iofflush.o iofopen.o iofputs.o \
+	   iofwrite.o ioputs.o iosetbuffer.o iosetvbuf.o \
+	   iovsprintf.o iovsscanf.o iovasprintf.o iovsnprintf.o
+		    
+XCFLAGS = $(LIBCFLAGS) -D_IO_USE_DTOA -D_IO_USE_LIBC
+XCXXFLAGS = $(LIBCXXFLAGS) -D_IO_USE_DTOA -D_IO_USE_LIBC
--- /dev/null	Wed Dec 31 16:00:00 1969
+++ libio/config/mtsafe.mt	Mon Aug 25 18:42:20 1997
@@ -0,0 +1,4 @@
+MTCFLAGS = -D_IO_MTSAFE_IO
+MTCXXFLAGS = -D_IO_MTSAFE_IO
+XCFLAGS = $(LIBCFLAGS) $(MTCFLAGS)
+XCXXFLAGS = $(LIBCXXFLAGS) $(MTCXXFLAGS)