This is the mail archive of the crossgcc@sourceware.org mailing list for the crossgcc project.
See the CrossGCC FAQ for lots more information.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
On 06 May 2007 18:57, Jonathan S. Shapiro wrote: > On Sun, 2007-05-06 at 18:37 +0100, Dave Korn wrote: > >>> Two concrete examples: >>> >>> Coyotos has no direct substitute for the time() family of functions. >>> Some of the classes in libstdc++ appear to require this. >> >> If there aren't autoconf tests that detect the lack of this function and >> disable whatever relies on it, you'll have to supply a dummy wrapper for >> your target. Just one that always returns a fixed time of the epoch would >> suffice; you'd simply have to remember not to use any libstdc++ functions >> that relied on times. > > This isn't good enough for our purposes. What we need to do is either > remove the dependent classes from our libstdc++ or make the underlying > functionality actually work. Well, the second one of those sounds like the better approach to me :) >> BTW, have you investigated whether the --disable-hosted-libstdcxx option >> might help? > > That would simplify matters, but it doesn't address the problem we > actually want to solve. If we don't want STL, there is really no reason > to build libstdc++ at all. The main reason to build libstdc++ is to get > the collection class templates. Ah, I didn't think it would exclude all those, that does seem a bit less-than-useful. > I'm well aware of how newlib deals with this. It misses the point. We > aren't trying to target a POSIX environment. The goal isn't to "stub > out" the signal() call. The goal is to eradicate all *dependencies* on > the signal() call. We can stub out the calls easily enough, but most > code that calls signal() is actually trying to accomplish something > purposeful. We generally have a way to accomplish that purpose; just not > through signal(). Right, you want to implement the same semantics through different methods, I see. > In order for the library to be truly portable, what needs to happen is > for these "implicit APIs" to be made explicit so that non-POSIX systems > can specify how to implement them. We're willing to make those changes > and submit those patches, but Ulrich has historically rejected such > things out of hand. > I don't know whether glibc on, say, VAX/VMS relied on autoconf or not. I > do know that glibc built there for a long time. We've actually got most > of the autoconf support we need in place. The problem is that stubbing > some of these things out actually isn't the right solution. No, I agree; it sounds like you need to *implement* them. > I think the real issue we are facing is missing abstraction boundaries > in the library implementations. It's hard to know what to do about that > in the face of uncooperative maintainers. The real issue, I think, is > that most of the library efforts are no longer trying to support any > non-UNIX target, and in consequence they have given up on the notion of > an OS abstraction layer in their library designs. I don't think that's entirely accurate. They /do/ have an "OS abstraction layer", and it conforms to POSIX. If you want to run glibc or stdlibc++-v3 on a non-POSIX system, can you not just build a POSIX-compatibility shim layer? Would switching to some completely new and non-standard OS interface spec really bring much by the way of benefits? Ultimately, the libraries have to assume /some/ kind of lower-edge interface; why not POSIX? cheers, DaveK -- Can't think of a witty .sigline today.... -- For unsubscribe information see http://sourceware.org/lists.html#faq
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |