`clever' C preprocessor trick now causes problems

[Eric Norum]

I'm using RTEMS as a platform for EPICS (Experimental Physics and
Industrial Control System).  The EPICS sources assume a full NFS
connection to the file server and opens files with pathnames like:
        ../foobar.dbd
        ../../db/bletch.db
        ./blahblahblah.cmd

To provide similar functionality on RTEMS I compile the EPICS sources
with a `-Dfopen=rtems_fopen' command-line flag.  The rtems_fopen routine
strips off any leading ./ or ../ characters, prepends
/TFTP/<<bootp_host>>/epics/<<hostname>>/ and then passes that name to
the real fopen routine.  Neat trick, huh?  I thought so too, at the
time.  Now I don't.  :-(

The problem is with the C++ headers in gcc-3.0.  In particular,
g++-v3/bits/std_cstdio.h which has:
.
.
.
#include <stdio.h>

// Get rid of those macros defined in <stdio.h> in lieu of real
functions.
.
.
.
#undef fopen
.
.
.
namespace std
{
.
.
.
  using ::fopen;


This of course causes an error since there' no prototype for fopen
because the command-line definition forces the prototype in stdio.h to
look like FILE *rtems_fopen (....

And yes, there are C++ source files that call fopen so I can't get
around the problem by just using the command-line redefinition for C
source files.

I'm at a bit of a loss as to how to get around this without hacking up
either the GCC header files or the EPICS source.  Till now I've been
able to avoid messing with either, and I'd like to keep it that way.

Suggestions?

-- 
Eric Norum                                 eric.norum at usask.ca
Department of Electrical Engineering       Phone: (306) 966-5394
University of Saskatchewan                 FAX:   (306) 966-5407
Saskatoon, Canada.