This is the mail archive of the
libc-alpha@sources.redhat.com
mailing list for the glibc project.
Re: glibc 2.1.1pre2 breaks libstdc++-v3 build
- To: drepper at cygnus dot com
- Subject: Re: glibc 2.1.1pre2 breaks libstdc++-v3 build
- From: "Kaveh R. Ghazi" <ghazi at caip dot rutgers dot edu>
- Date: Thu, 11 Jan 2001 16:28:56 -0500 (EST)
- Cc: gcc-bugs at gcc dot gnu dot org, ghazi at caip dot rutgers dot edu, jsm28 at cam dot ac dot uk, libc-alpha at sources dot redhat dot com, libstdc++ at gcc dot gnu dot org
> From: Ulrich Drepper <drepper@redhat.com>
>
> "Joseph S. Myers" <jsm28@cam.ac.uk> writes:
>
> > (a) Is this really a good idea, or should such changes printf -> fprintf
> > not rather be achieved by extracting "stdout" somehow (as discussed on the
> > gcc lists from time to time) in GCC?
>
> No. Stdout is defined to be a macro which the compiler cannot know about.
As I mentioned in my last message, you can capture the definition of a
macro inside an inline function:
> extern __inline__ FILE *__builtin_stdout(void) { return stdout; }
Then you'd be essentially doing this transformation:
printf(...) -> fprintf(__builtin_stdout(), ...)
Alternatively, it occurs to me that since gcc now has an integrated
preprocessor, I bet you could grab the definition of stdout directly
from cpplib. But I haven't investigated that at all, yet...
--Kaveh
--
Kaveh R. Ghazi Engagement Manager / Project Services
ghazi@caip.rutgers.edu Qwest Internet Solutions