proto conflict, dwarf1 err, cpp oddity, Re: libstdc++v3 portability problems

[Robert Lipe <robertlipe at usa dot net>]

Phil Edwards wrote:

> [As a side note, please cc any future libstdc++-v3 issues to the libstdc++-v3
> list.  It's easy for things to get swamped in the gcc list.]

Is it correct decorum to use libstdc++ _and_ gcc/gcc-patches?


Here are my latest forms of punishment.

On OpenServer, the libstdc++ build of complex.cc would choke.  Looking
at the preprocesor output[1], I found curious prototypes of the form:

# 43 "/play/egcs/libstdc++-v3/include/c/bits/std_cstdlib.h" 2 3

namespace std
{
  using ::div_t;
  using ::ldiv_t;
# 61 "/play/egcs/libstdc++-v3/include/c/bits/std_cstdlib.h" 3
  extern "C" double atof(const char*);
[ munch ] 
  extern "C" ldiv_t ldiv(long int, long int);
  extern "C" int mbtowc((wchar_t *)0, const char*, size_t);	<-----! Look
  extern "C" int mbtowc(wchar_t*, const char*, size_t);
  extern "C" int wctomb(char*, wchar_t);
  extern "C" size_t mbstowcs(wchar_t*, const char*, size_t);
  extern "C" size_t wcstombs(char*, const wchar_t*, size_t);
# 115 "/play/egcs/libstdc++-v3/include/c/bits/std_cstdlib.h" 3
  extern "C" long double strtold(const char*, char**);

}
# 41 "/play/egcs/libstdc++-v3/include/c/bits/std_cmath.h" 2

I chased this back up and into the system <stdlib.h>   Sure enough, it
contains:
 
#define mblen(s, n)     mbtowc((wchar_t *)0, s, n)

I don't know the rules of C++ (and I agree this is an obnoxious system
definition) but I think it's quite legal for headers in C to do that.
So when we "reprototype" it, we're hosed.  Should I fixinclude this
away, or should libstdc++ deal with this possibility?


Just to not get bogged down (further) in this, I hand-fixed the version
in gcc/include and tried to continue the build.  No dice.

/play/negcs/gcc/g++ -B/play/negcs/gcc/ -nostdinc++ -L/play/negcs/i686-pc-sco3.2v
5.0.6/libstdc++-v3/src -L/play/negcs/i686-pc-sco3.2v5.0.6/libstdc++-v3/src/.libs
 -B/usr/local/i686-pc-sco3.2v5.0.6/bin/ -B/usr/local/i686-pc-sco3.2v5.0.6/lib/ -
isystem /usr/local/i686-pc-sco3.2v5.0.6/include -nostdinc++ -I/play/egcs/libstdc
++-v3/include/std -I/play/egcs/libstdc++-v3/include/c -I/play/egcs/libstdc++-v3/
libsupc++ -I/play/egcs/libstdc++-v3/include -I../libio -I/play/egcs/libstdc++-v3
/libio -I/play/egcs/libstdc++-v3/libmath -I../include -fno-implicit-templates -W
all -Wno-format -W -Wwrite-strings -Winline -fdiagnostics-show-location=once -ff
unction-sections -fdata-sections -g -c /play/egcs/libstdc++-v3/src/complex_io.cc

/play/egcs/libstdc++-v3/src/complex_io.cc:0: warning: -ffunction-sections may
   affect debugging on some targets.
(EOF):undefined name: .L_E20431
(EOF):undefined name: .L_E20406
(EOF):undefined name: .L_E20394
(EOF):undefined name: .L_E26404
(EOF):undefined name: .L_E26358
(EOF):undefined name: .L_E26324
make[2]: *** [complex_io.lo] Error 1
make[1]: *** [all-recursive] Error 1

If I make the '-g' into "-gdwarf-2", this error goes away.  (This is a
dwarf-1 target.)

[1] Are others seeing incredibly ugly output from cpp sometimes?  It
seems to be related to the presence of -P.

$ cat /tmp/x.cc
#include "/play/egcs/libstdc++-v3/include/c/bits/std_cstdlib.h"

If I 'cc -E' the file, I get:
  extern "C" div_t div(int, int);
  extern "C" ldiv_t ldiv(long int, long int);
  extern "C" int mblen(const char*, size_t);
  extern "C" int mbtowc(wchar_t*, const char*, size_t);
  extern "C" int wctomb(char*, wchar_t);
  extern "C" size_t mbstowcs(wchar_t*, const char*, size_t);
  extern "C" size_t wcstombs(char*, const wchar_t*, size_t);
# 117 "/play/egcs/libstdc++-v3/include/c/bits/std_cstdlib.h" 3
}

But i 'cc -E -P' the same file, I get:

                                       const
                                             char
                                                 *
                                                  ,
                                                    size_t
                                                          )
                                                           ;
  extern
         "C"
             size_t
                    wcstombs
                            (
                             char
                                 *
                                  ,
                                    const
                                          wchar_t
                                                 *
                                                  ,
                                                    size_t
                                                          )
                                                           ;
}


What's up with that?

RJL