This is the mail archive of the
mailing list for the GCC project.
Re: Restore __eprintf
- To: Jeffrey Oldham <oldham at codesourcery dot com>
- Subject: Re: Restore __eprintf
- From: "Zack Weinberg" <zackw at Stanford dot EDU>
- Date: Tue, 29 May 2001 21:25:30 -0700
- Cc: gcc-patches at gcc dot gnu dot org
On Tue, May 29, 2001 at 04:35:05PM -0700, Jeffrey Oldham wrote:
> My recent upgrade to the latest dejagnu for mips-sgi-irix6.5 revealed
> hundreds of libstdc++-v3 test failures all because `__eprintf' is
> declared but not defined. __eprintf() is declared in a
> mips-sgi-irix6.5/include/assert.h. assert.h is included by
> libstdc++-v3/include/c_std/bits/std_cassert.h. See the attached file
> for an example.
mips-sgi-irix6.5/include/assert.h was installed by an older version of
the compiler. Your problem should go away if you remove that file.
However, I can see this happening in a context where the file cannot
> gcc/Makefile.in includes `__eprintf' in LIB2FUNCS_ST. These functions
> are included only in the static library version. Unfortunately, the
> `-static' flag is, in practice, ignored for Irix. The only solution I
> see is to remove all uses of `__eprintf' in all the gcc source code
> and then comment LIB2FUNCS_ST as being dangerous since `-static' does
> not work on some machines.
All uses of __eprintf have already been purged from the gcc tree.
Your situation is precisely why we put it back - older installations
place their <assert.h>, which uses __eprintf, in a location which is
still searched by the newer compiler. [We never should have installed
it there in the first place, but it's too late to fix that by at least
I'm not sure what you mean by 'the -static flag is in practice ignored
for Irix.' Is the C++ compiler linking executables with the shared
libgcc and not the static libgcc? I was under the impression that
both were used in the -shared-libgcc case.
One fix is to remove $(tooldir) from cpp's search path. This would
actually enable the removal of a moderately large amount of crap from
the Makefiles, the gcc driver, and the preprocessor (You Don't Want To
Know, trust me). If gcc's assert.h is the only header that was ever
installed there by anything, we could get away with that, but I dimly
remember that binutils might install headers in
$prefix/$target_alias/include (== $tooldir) under some conditions.
Failing that, we're probably stuck putting __eprintf back in
libgcc_s.so and freezing it into the library interface. Bugger.
zw I *will* wrestle it into shape eventually. I *will* clean it out,
*without* resorting to the redirection of a major navigable river.
-- Ray Radlein on lumber rooms