RE: another proposed crosstool project

["Dave Korn" <dave dot korn at artimi dot com>]

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