Re: (Some) C++ support?

> What about some C++ support, after all?

I have no fundamental problem with that.

Unfortunately, there are a few obstacles,

First of all, to even link a C++ program with dietlibc, you cannot use
libstdc++ (iostreams, STL) because those depend on undocumented internal
features of glibc that we do not support.  We would have to provide our
own STL implementation.

And if you have a program that does not use STL, dietlibc still needs to
supply some functions for parsing ELF debug symbols because that's how
C++ exception handling works on Linux.  The compiler generates code
using those functions, and we don't have them.

> sqapi.cpp:(.text._ZN13SQCollectableD0Ev[_ZN13SQCollectableD5Ev]+0x1f): undefined reference to `operator delete(void*)'
> squirrel/sqapi.o:(.rodata._ZTV13SQCollectable[vtable for SQCollectable]+0x10): undefined reference to `__cxa_pure_virtual'

> operator delete(void*p) would be just { free(p); }
> and __cxa_pure_virtual() - { abort(); }

LOL

> Just as extra note, before I patched "diet", the source was compiled
> against glibc headers, and was plagued by _FORTIFY_SOURCE curse. After
> I disabled it (-U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=0), it turned out
> that when linking with static -lstdc++, then -lstdc++ contains code
> compiled with _FORTIFY_SOURCE, so it's of all those *_chk symbols. So,
> I even wanted to ask about an idea to provide compatibility lib, which
> would just remap glibc's *_chk symbols into original function calls,
> but it all was much better fixed my patching "diet" to not be afraid of
> g++. And if aiming for "C++ stdlib" support, then using saner
> (than glibc's libstdc++) solutions like STLPort seems like better idea.

I think a better approach than STLport would be to look at the libc++
from clang/llvm as a starting point.  If we support C++, we might as
well go all in and use C++11.

Felix