Re: (Some) C++ support?

Hello,

On Wed, 14 Aug 2013 22:19:49 +0200
Felix von Leitner <[email protected]> wrote:

> > 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.

Or rather, use existing unbloated STL implementation, as discussed
below.

> 
> 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.

Exceptions?! No, supporting those in dietlibc didn't even come to my
mind. Before even using them, there should be decent implementation of
them in mainstream compilers, not typical setjmp/longjmp crap how it
was few years ago, so now everyone just dreads to use them. Exceptions
and RTTI of course have their uses too, but I don't remember seeing not
too big C++ app lately which wouldn't use -fno-exceptions -fno-rtti.

> 
> > 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

And yet I mean just that ;-). It is helpful already (Squirrel builds
and kinda runs, unfortunately there's no testsuite to do regression
testing), and can be basis for any future effort (by whoever needs
more).

Of course, it would be too childish to call that -lstdc++ in dietlibc,
but it could very well go into something like -lc++supp IMHO.

> 
> > 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.

Well, my mentioning of STL support was based on the idea that it still
would be useful for not too big apps. For example, a package manager
could easily use maps, lists and vectors. And a package manager would
be natural target to be compiled against dietlibc. Mentioning STLPort
was in turn based on knowing that folks use it on AVR MCU:
https://github.com/vancegroup/stlport-avr . Something usable on AVR
should be good enough to use with dietlibc, the opposite may not be
true.

All in all, I just wanted to report that it takes fairly minor changes
to build no-nonsense example of unbloated C++ code OOB with dietlibc,
and leave some ideas in the ML archive for whoever may look for that
(my quick look at gmane archive didn't bring any recent threads).

I'll try to prepare patches then.

> 
> Felix



-- 
Best regards,
 Paul                          mailto:[email protected]