This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
v3 link failures analyzed
- To: libstdc++ at gcc dot gnu dot org
- Subject: v3 link failures analyzed
- From: Robert Lipe <robertl at sco dot com>
- Date: Sat, 30 Dec 2000 16:06:30 -0600
- Cc: gcc at gcc dot gnu dot org
Here's an interesting kink. I suspect that this will show up in a
couple of different host environments that offer different degrees of
masochism for standards conformance.
On OpenServer's GCC, "-ansi" actually picks up a different set of
includes (/us/rinclude/ansi instead of /usr/include) that offers a
namespace that's restricted to that of ANSI C. For example, ISO
C doesn't offer sqrtf so the system in -ansi mode mustn't offer a
prototype for it in math.h. This is parallel to a similar behaviour
(although with a slightly different invocation spelling) of the native
compiler.
Here's the catch: When libstdc++-v3 builds config.h, '-ansi' is not
present on the compilation line so we #define HAVE_SQRTF 1. This
results in include/bits/c++config.h getting _GLIBCPP_HAVE_SQRTF set,
too.
Now, at testsuite time, we come along and build a line like this:
spawn /play/negcs/gcc/testsuite/../g++ -B/play/negcs/gcc/testsuite/../ /play/egc
s/gcc/testsuite/g++.old-deja/g++.law/ctors6.C -nostdinc++ -I/play/negcs/i686-pc-
sco3.2v5.0.6//libstdc++-v3/include -I/play/egcs/libstdc++-v3/include/std -I/play
/egcs/libstdc++-v3/include/c_std -I/play/egcs/libstdc++-v3/include -I/play/egcs/
libstdc++-v3/libsupc++ -I/play/egcs/libstdc++-v3/libio -I/play/egcs/libstdc++-v3
/testsuite -I/play/egcs/libstdc++-v3/include/backward -I/play/egcs/libstdc++-v3/
include/ext -fmessage-length=0 -ansi -pedantic-errors -Wno-long-long -c -fPIC -o
/play/negcs/gcc/testsuite/ctors6.o ^M
The key here is the presence of "-ansi" near the end. Since the autoconf
gibberish thinks we really do have sqrtf, we try to use it thusly:
#elif _GLIBCPP_HAVE_SQRTF
inline float
sqrt(float __x) { return ::sqrtf(__x); }
#else
inline float
The problem is that the <math.h> we're using (since we're -ansi) is more
restricted than the one we tested with autoconfig. Thus, we don't have
sqrtf and the compile goes up in smoke.
It seems to me that the -ansi-ness of the testsuite invocation needs to
match that of the autoconf invocation, but I could be talked out of that.
Although my example picks on sqrtf, there are actually about a dozen
such affected functions in math.h alone. Advice?
RJL