[haiku-commits] Re: BRANCH midar-github.master - src/system/libroot/posix/glibc/stdio-common src/servers/app src/kits/app src/apps/icon-o-matic/shape headers/os/support
- From: pulkomandy <pulkomandy@xxxxxxxxxxxxx>
- To: haiku-commits@xxxxxxxxxxxxx
- Date: Sun, 25 Nov 2012 15:36:46 +0100
On Sun, Nov 25, 2012 at 03:18:04PM +0100, Jonathan Schleifer wrote:
> Am 25.11.2012 um 15:02 schrieb pulkomandy:
>
> > I don't see why. We use it in the Kernel in Haiku, and I already used it
> > at lower levels in some other projects (you can get the reset vectors
> > for a Cortex-M3 processor written entirely in C++, for example). Has
> > libc a very special exception to that ?
>
> Yes. It means that you always have to pull in C++ which is not fully
> compatible with C. In every C application.
>
> It also means that static linking will be broken: You suddenly have to
> specify -lstdc++ to link a C program, as dependencies are only resolved for
> shared libraries.
You don't require stdc++ for many C++ features. As I said, it's possible
to use part of C++ from the reset vector of a CPU, which is as low-level
as it gets for executable code.
>
> That whole file is ugly (like the rest of this ancient glibc), so I don't see
> why we should really bother? We should instead focus on importing a newer and
> more sane libc for gcc4.
Well, we're going to stick with it for the gcc2 part of the system for
quite some time. So I'd either go with :
* Start using something else for gcc4/clang, and stop hacking this one now
(in this case it's ok to keep the gccisms in this one)
* Or clean it up if we want to use it for gcc4/clang, but then do it
properly, not by further messing up the code.
I think the 1st approach sounds better in the long term. So, why these
changes in this part of the code ?
--
Adrien.
Other related posts:
