No subject

------- Additional Comments From silakov at ispras.ru  2007-04-28 07:06
-------
Well, I think you have correctly understood the complexity of this bug.
Simply=20
instead of adding a lot of extra records in other tables we've moved
basetype=20
to ArchType table and rewritten all scripts which use basetype. It was
not as=20
easy as applying this new patch.

But for final decision for this bug, I think we'd better wait for a
nightly=20
build of the lsb sdk with the patch applied and try to compile the
"Hello,=20
world" example.

As for c++ piece, it comes from mkheader script. The thing is that
wchar_t is=20
marked as 'conly' (Tconly=3D'Yes'), and mkheader encapsulates such types
with=20
'!__cplusplus' ifdefs. Unfortunately, the same thing is not supported
for=20
constants now (neither by db schema nor by scripts). But I think
implementing=20
it will not take a long time, we'll take a look at #1186.
-------

So the complexity was there, but was all in the work of refactoring
this part of the database...=20

The build didn't seem to have any problems, but then I didn't really
expect any since there were also no problems for the entire autobuild
sequence on ia32/ppc32 with the old, incorrect, setting for wchar_t.

I've pulled down lsb-build-base from the snapshots tree, and it
includes the corrected header; the test program in the bug now
builds right with lsbcc as a result.