This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: PR libstdc++/17505: Update libmath stubs in linker-map.gnu
- From: Roger Sayle <roger at eyesopen dot com>
- To: Richard Henderson <rth at redhat dot com>
- Cc: gcc-patches at gcc dot gnu dot org, <libstdc++ at gcc dot gnu dot org>
- Date: Wed, 6 Oct 2004 18:35:03 -0600 (MDT)
- Subject: Re: PR libstdc++/17505: Update libmath stubs in linker-map.gnu
On Wed, 6 Oct 2004, Richard Henderson wrote:
> On Sun, Oct 03, 2004 at 11:57:04AM -0600, Roger Sayle wrote:
> > * config/linker-map.gnu: Synchronize the current list of stub
> > functions from libmath.
>
> For the record, I don't think that this is a terribly good idea.
>
> Better would be to put all of these routines in a separate library
> such that the search path becomes
>
> -lstdc++
> -lm
> -lm_compat
>
> where -lm_compat is our compatibility library. In this way, the user
> gets to take advantage of C99 compatibility improvements in the host
> operating system. It also insulates libstdc++ itself from having to
> become a compltete libc replacement. It can also be reused by libgfortran,
> which basically has to do exactly the same thing.
Whilst I agree that such a solution makes a great deal of sense
technically, I'd just be worried by the politics of such a decision.
The GNU project already has glibc, newlib and libiberty fighting over
thier roles in the grand scheme of things, adding a GCC based libm_compat
of currently poorly written math routines may make the situation worse
instead than better. Not to mention libgcc and libunwind.
Perhaps an alternative might be to have glibc, which already contains
"correct" implementations of all of the necessary support routines, to
be built as a symbiotic "/usr/local/lib/libglibc.a" that supplements the
host's missing functionality. This layer could provide long double and
other POSIX support to early versions of AIX, HPUX, IRIX, Solaris etc...
rather than glibc's current primary goal as a full libc replacement.
GCC's configure machinery could then test for -lglibc at build time,
and maybe even refuse to build non C languages if the host's system
libraries are insufficient.
Whilst I agree that the duplication between libstc++-v3/libmath/stubs.c
and libgfortran/intrinsics/c99_functions.c is undesirable, they really
are "stub" routines little better than assert ("No yet implemented!").
I'd rather we fixed the problem than shared the band-aid, but clearly
the current situation is less than desirable.
Roger
--