[haiku-development] Re: Include path for glibc-specific stuff?

  • From: Ingo Weinhold <ingo_weinhold@xxxxxx>
  • To: haiku-development@xxxxxxxxxxxxx
  • Date: Tue, 30 Jun 2009 12:31:07 +0200

On 2009-06-30 at 11:05:23 [+0200], Oliver Tappe <zooey@xxxxxxxxxxxxxxx> wrote:
> On 2009-06-30 at 10:44:45 [+0200], Oliver Tappe <zooey@xxxxxxxxxxxxxxx> 
> wrote:
> > 
> > as I'm still working on the compilers, here's another question:
> > 
> > I'd like to introduce the glibc-specific 'printf.h' header, since our 
> > libroot
> > contains the respective functions and we pretend to support those, too, by
> > declaring _G_HAVE_PRINTF_FP in _G_config.h.
> 
> Having looked a bit more at printf_size and friends, and having learnt that 
> it
> really is implemented by glibc only,

IIRC, FreeBSD has those features too, as part of their GNU compatibility.

> I am going to try and find a way around
> it during the native build of haiku's libstdc++. If I manage to do that, I'm
> going to remove the respective functions from libroot.
> If I can't figure that out, I'd like to follow Ingo's suggestion in a
> corresponding ticket and just leave it alone and copy libstdc++.r4.so from 
> the
> cross build - *if* gcc4 has no such dependency (and I doubt it has).

Don't invest too much time in the gcc 2 build. IMHO it's just not worth it. 
The status quo works well enough.

What we should improve is the gcc 4 build, particularly building shared 
libsupc++ and libstdc++ on cross-compilation. This would require building a 
mini bootstrap libroot during the configure process, I guess.

> > But I suppose both headers (printf.h and _G_config.h) should live in a
> > special folder, as they are not POSIX. Judging by BEINCLUDES, we could 
> > revive
> > 'headers/gnu' or shall we go for 'headers/glibc' instead?

We renamed "gnu" to "3rdparty". I wouldn't reintroduce the former. "glibc" 
would be the better choice IMHO. I wouldn't mind leaving things as they are, 
though. The headers aren't POSIX, that's right, but there are a few things 
that aren't (strictly) POSIX. Renaming "posix" to "libc" or "libroot" would 
be more accurate, but some of the libroot functionality is exposed by headers 
in "os", so that's not a perfect solution either.

> > Do you know of any other, existing headers that should be moved there?

Not ATM at least.

CU, Ingo

Other related posts: