On 11/25/2012 08:05 PM, Jonathan Schleifer wrote:
Am 25.11.2012 um 15:39 schrieb Ingo Weinhold:I'm not aware of any incompatibilities. Care to elaborate?C is not a subset of C++, they are, in fact, two different languages. The list of differences is quite long, actually. See http://en.wikipedia.org/wiki/Compatibility_of_C_and_C%2B%2B
From a quick scan I see nothing that would be relevant past compile-time. IOW there's nothing preventing us for mixing both C and C++ in the implementation of a library. And with the usual precautions exporting both C and C++ interfaces isn't an issue either.
We don't have a static libroot and since ATM there are no plans for a binary compatible kernel interface, there probably won't be any anytime soon (at least it wouldn't make much sense).So we should just never allow static binaries then, just to fix a glibc issue that can be fixed without adding a C++ dependency?
The only advantage of static linking is to get an executable that is independent of any shared libraries. The resulting executable will, however, depend on private interfaces/protocols (libroot-kernel, libroot-registrar, maybe others) instead. So for Haiku static linking simply doesn't make any sense in this case anyway. No point in theorizing how using C++ in libroot would affect it.
You'll be horrified to learn that our libroot already uses C++. The gcc 4 version is statically linked against libsupc++. Both gcc 2 and gcc 4 have also compiled in libgcc. For gcc 2 we can't really change that. For gcc 4 we should eventually disentangle things (i.e. link against the shared libgcc and libsup++ instead).Yes, that sounds sane. After all, there is not much sense in linking libsup++ for a pure C program.
That's not what I'm saying. My point is that libroot should link against a shared libgcc and a shared libsupc++ (instead of statically linking against those, now) to avoid tying it to a specific compiler version and possibly causing issues when a program is built with a newer compiler. The dependencies wouldn't change, though. libroot would still use C++ and even a pure C program would (indirectly) cause libsupc++ to be loaded.
What happened to the patch to add a BSD-based libc, btw?
IIRC it had not been ready for inclusion -- i.e. was unstable and possibly even not quite complete -- and there haven't been any follow-ups I'm aware of. Don't know, if the patch itself is still around.
CU, Ingo
