base gcc and _GLIBCXX_USE_C99

[Dimitry Andric]

On 2013-02-01 15:46, Pedro Giffuni wrote:
> On 02/01/2013 08:01, Andriy Gapon wrote:
>> on 28/01/2013 17:11 Andriy Gapon said the following:
>>> I wonder why the following is the case for the base gcc.
>>> /usr/include/c++/4.2/bits/c++config.h:
>>>
>>> /* Define if C99 functions or macros from <wchar.h>, <math.h>, <complex.h>,
>>>      <stdio.h>, and <stdlib.h> can be used or exposed. */
>>> /* #undef _GLIBCXX_USE_C99 */
>>>
>>> Because of this undef there is no e.g. std::strtoll().
>>> Ditto for other things in stdlib.h.
>>>
> I looked at this very briefly and it looks like it would fix a nasty
> issue we have been working around in OpenOffice.
>
> I suggest to enable it first on a gcc port though (it's tied to a
> configure flag, but don't remember which).

I had a bit more in-depth look at our current libstdc++ configuration.

I took the original gcc 4.2.1 release tarball, modified a few autoconf
related scripts to cope with "freebsd10.0" being the current version,
and did a full three-stage build, though only targeting C and C++.

The libstdc++ configure script in 4.2.1 does detect a few new features
that are not in our shipping config.h, but is does not detect any
different settings regarding C99.

The reason it does not turn on _GLIBCXX_USE_C99, is that not all of the
C99 requirements are met, specifically <complex.h> checks fail:

   checking for ISO C99 support in <math.h>... yes
   checking for ISO C99 support in <complex.h>... no
   checking for ISO C99 support in <stdio.h>... yes
   checking for ISO C99 support in <stdlib.h>... yes
   checking for ISO C99 support in <wchar.h>... yes
   checking for fully enabled ISO C99 support... no

The exact failure testcase goes like this:

   configure:7435: checking for ISO C99 support in <complex.h>
   configure:7492:  /home/dim/obj/gcc-4.2.1/./gcc/xgcc -shared-libgcc -B/home/dim/obj/gcc-4.2.1/./gcc -nostdinc++ -L/home/dim/obj/gcc-4.2.1/i386-unknown-freebsd10.0/libstdc++-v3/src -L/home/dim/obj/gcc-4.2.1/i386-unknown-freebsd10.0/libstdc++-v3/src/.libs -B/home/dim/ins/gcc-4.2.1/i386-unknown-freebsd10.0/bin/ -B/home/dim/ins/gcc-4.2.1/i386-unknown-freebsd10.0/lib/ -isystem /home/dim/ins/gcc-4.2.1/i386-unknown-freebsd10.0/include -isystem /home/dim/ins/gcc-4.2.1/i386-unknown-freebsd10.0/sys-include -c -g -O2   conftest.cc >&5
   conftest.cc: In function 'int main()':
   conftest.cc:41: error: 'clogf' was not declared in this scope
   conftest.cc:47: error: 'cpowf' was not declared in this scope
   conftest.cc:54: error: 'clog' was not declared in this scope
   conftest.cc:60: error: 'cpow' was not declared in this scope
   conftest.cc:64: error: 'ccosl' was not declared in this scope
   conftest.cc:65: error: 'ccoshl' was not declared in this scope
   conftest.cc:66: error: 'cexpl' was not declared in this scope
   conftest.cc:67: error: 'clogl' was not declared in this scope
   conftest.cc:68: error: 'csinl' was not declared in this scope
   conftest.cc:69: error: 'csinhl' was not declared in this scope
   conftest.cc:71: error: 'ctanl' was not declared in this scope
   conftest.cc:72: error: 'ctanhl' was not declared in this scope
   conftest.cc:73: error: 'cpowl' was not declared in this scope
   configure:7498: $? = 1

So until we actually implement and declare those functions, we should
probably not enable _GLIBCXX_USE_C99_COMPLEX and _GLIBCXX_USE_C99.

I have attached a diff of the other changes that can be applied on our
current libstdc++ config file, as detected by the configure script.  I
will probably commit that soonish, if there are no objections.

As to the missing complex functions, I am not sure.  Maybe these can be
imported from somewhere else, e.g. NetBSD?  This is probably something
to ask the lib/msun specialists...

-Dimitry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: libstdcxx-reconfig-1.diff
Type: text/x-diff
Size: 1970 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-toolchain/attachments/20130203/5751616f/attachment.diff>