Closed dmik closed 4 years ago
Read the original ticket for more info. In particular, a few changes should be undone one this issue is resolved. These include:
https://github.com/bitwiseworks/qtdeclarative-os2/commit/e7a97582cd3174aaa5c8533df37fe86efdc5f740
Note that the LIBC part of wide char support is done within https://github.com/bitwiseworks/libc/issues/8.
Also note that we should keep wchar_t
and wint_t
definitions in the EMX target for GCC in sync with LIBC. wchar_t
is currently fine (unsigned short
in both cases) but wint_t
is not (int
in LIBC and unsigned int
in GCC). I will fix it within this ticket as well.
std::is_integral<wchar_t>::value
is false
ATM, this breaks Chromium and needs to be dealt with. I guess we must force --enable-wchar_t
for now and pray that it doesn't blow somewhere. And if it blows, #if 0
such places with a reference to this ticket as a temporary solution.
With the latest wprinf
changes to LIBC, the number of the missing functions has shortened to this in conftest responsible for this setting to be automatically enabled:
t2.cpp:40:12: error: '::fgetwc' has not been declared
40 | using ::fgetwc;
| ^~~~~~
t2.cpp:41:12: error: '::fgetws' has not been declared
41 | using ::fgetws;
| ^~~~~~
t2.cpp:43:12: error: '::fputws' has not been declared
43 | using ::fputws;
| ^~~~~~
t2.cpp:46:12: error: '::fwscanf' has not been declared
46 | using ::fwscanf;
| ^~~~~~~
t2.cpp:47:12: error: '::getwc' has not been declared
47 | using ::getwc;
| ^~~~~
t2.cpp:48:12: error: '::getwchar' has not been declared
48 | using ::getwchar;
| ^~~~~~~~
t2.cpp:56:12: error: '::swscanf' has not been declared
56 | using ::swscanf;
| ^~~~~~~
t2.cpp:57:12: error: '::ungetwc' has not been declared
57 | using ::ungetwc;
| ^~~~~~~
t2.cpp:90:12: error: '::wscanf' has not been declared
90 | using ::wscanf;
| ^~~~~~
fputws
was somehow lost when doing https://github.com/bitwiseworks/libc/commit/59105a4d893e83721c4649a0bafd0b9d84d01845. The rest are scan/get functions that were never done so far. It may take a while to do them.
No, forcing --enable-wchar_t
w/o bringing the above functions to LIBC is not an option. It brings a lot of side effects. E.g. simply #include <cwchar>
in the C++ source code will bring virtually the same error message as above (expected). We have to add those functions to LIBC to continue on Chromium.
With https://github.com/bitwiseworks/libc/issues/8 resolved, this issue goes away: libstdc++v3 configure can detect wchar_t function presence now and imply --enable-wchar_t
by default. Closing this.
I need to reopen this as I get build errors when trying to rebuild GCC from scratch. Some conflict with 2eafb765c8c7e63f7d481b2ac32fa51f34085899 it seems:
ctype_members.cc:137:3: error: redefinition of 'bool std::ctype<wchar_t>::do_is(std::ctype_base::mask, std::ctype<wchar_t>::char_type) const'
137 | ctype<wchar_t>::
| ^~~~~~~~~~~~~~
In file included from D:/Users/dmik/rpmbuild/BUILD/gcc-9.2.0/libstdc++-v3/include/bits/locale_facets.h:1538,
from D:/Users/dmik/rpmbuild/BUILD/gcc-9.2.0/libstdc++-v3/include/std/locale:40,
from ctype_members.cc:31:
D:/Users/dmik/rpmbuild/BUILD/gcc-9.2.0/libstdc++-v3/config/os/os2/ctype_inline.h:109:3: note: 'virtual bool std::ctype<wchar_t>::do_is(std::ctype_base::mask, wchar_t) const' previously defined here
109 | ctype<wchar_t>::
| ^~~~~~~~~~~~~~
ctype_members.cc:155:3: error: redefinition of 'const wchar_t* std::ctype<wchar_t>::do_is(const wchar_t*, const wchar_t*, std::ctype_base::mask*) const'
155 | ctype<wchar_t>::
| ^~~~~~~~~~~~~~
In file included from D:/Users/dmik/rpmbuild/BUILD/gcc-9.2.0/libstdc++-v3/include/bits/locale_facets.h:1538,
from D:/Users/dmik/rpmbuild/BUILD/gcc-9.2.0/libstdc++-v3/include/std/locale:40,
from ctype_members.cc:31:
D:/Users/dmik/rpmbuild/BUILD/gcc-9.2.0/libstdc++-v3/config/os/os2/ctype_inline.h:116:3: note: 'virtual const wchar_t* std::ctype<wchar_t>::do_is(const wchar_t*, const wchar_t*, std::ctype_base::mask*) const' previously defined here
116 | ctype<wchar_t>::
| ^~~~~~~~~~~~~~
ctype_members.cc:173:3: error: redefinition of 'const wchar_t* std::ctype<wchar_t>::do_scan_is(std::ctype_base::mask, const wchar_t*, const wchar_t*) const'
173 | ctype<wchar_t>::
| ^~~~~~~~~~~~~~
In file included from D:/Users/dmik/rpmbuild/BUILD/gcc-9.2.0/libstdc++-v3/include/bits/locale_facets.h:1538,
from D:/Users/dmik/rpmbuild/BUILD/gcc-9.2.0/libstdc++-v3/include/std/locale:40,
from ctype_members.cc:31:
D:/Users/dmik/rpmbuild/BUILD/gcc-9.2.0/libstdc++-v3/config/os/os2/ctype_inline.h:140:3: note: 'virtual const wchar_t* std::ctype<wchar_t>::do_scan_is(std::ctype_base::mask, const wchar_t*, const wchar_t*) const' previously defined here
140 | ctype<wchar_t>::
| ^~~~~~~~~~~~~~
ctype_members.cc:182:3: error: redefinition of 'const wchar_t* std::ctype<wchar_t>::do_scan_not(std::ctype_base::mask, const char_type*, const char_type*) const'
182 | ctype<wchar_t>::
| ^~~~~~~~~~~~~~
In file included from D:/Users/dmik/rpmbuild/BUILD/gcc-9.2.0/libstdc++-v3/include/bits/locale_facets.h:1538,
from D:/Users/dmik/rpmbuild/BUILD/gcc-9.2.0/libstdc++-v3/include/std/locale:40,
from ctype_members.cc:31:
D:/Users/dmik/rpmbuild/BUILD/gcc-9.2.0/libstdc++-v3/config/os/os2/ctype_inline.h:149:3: note: 'virtual const wchar_t* std::ctype<wchar_t>::do_scan_not(std::ctype_base::mask, const char_type*, const char_type*) const' previously defined here
149 | ctype<wchar_t>::
| ^~~~~~~~~~~~~~
ctype_members.cc: In member function 'virtual char std::ctype<wchar_t>::do_narrow(wchar_t, char) const':
ctype_members.cc:212:14: warning: comparison is always true due to limited range of data type [-Wtype-limits]
212 | if (__wc >= 0 && __wc < 128 && _M_narrow_ok)
| ~~~~~^~~~
ctype_members.cc: In member function 'virtual const wchar_t* std::ctype<wchar_t>::do_narrow(const wchar_t*, const wchar_t*, char, char*) const':
ctype_members.cc:226:14: warning: comparison is always true due to limited range of data type [-Wtype-limits]
226 | if (*__lo >= 0 && *__lo < 128)
| ~~~~~~^~~~
Got one more problem when linking STDCPP6.DLL now:
weakld: error: Unresolved symbol (UNDEF) '_wcsxfrm'.
weakld: info: The symbol is referenced by:
D:\Temp\ldconv_collate_members_o_6ff95e7155bf183d60.obj
D:\Temp\ldconv_collate_members_cow_o_6ff95e7155bf187fc8.obj
Ignoring unresolved externals reported from weak prelinker.
Error! E2028: _wcsxfrm is an undefined reference
file D:/Temp\ldconv_collate_members_o_6ff95e7155bf183d60.obj(collate_members.cc): undefined symbol _wcsxfrm
file D:/Temp\ldconv_collate_members_cow_o_6ff95e7155bf187fc8.obj(collate_members_cow.cc): undefined symbol _wcsxfrm
Which means that this one was not required by configure so it didn't fall. Sigh. I will have to add it to LIBC or make GCC not use it. I.e. more time on this.
Now all builds but I've faced https://github.com/bitwiseworks/libc/issues/35 during another round. Need to investigate it further.
Couldn't move further with the make break investigation, it just worked upon the next time. This is irrelevant to this ticket though so I'm going to close it — rebuilt GCC fully supports wchar_t in all my tests (QtBase/QtDeclarative with rolled back hacks, QtWebEngine, even wregex works).
From https://github.com/psmedley/gcc/issues/30:
IIRC this is disabled by configure now because kLIBC doesn't implement all necessary wide character functions (so the respective configure test fails).
When enabled, gcc defines
_GLIBCXX_USE_WCHAR_T
which enables special code for wide characters. This code includes e.g. astd::is_integral<wchar_t>
specialization returningtrue
instead offalse
and a lot of other things.The problem was found while working on the
QTypeInfo<wchar_t>
specialization for Qt 5 within https://github.com/bitwiseworks/qtbase-os2/issues/29.Note that we may force such support with
--enable-wchar_t
but a test build needs to be done to check if it will work with our kLIBC.