RE: another proposed crosstool project

["Jonathan S. Shapiro" <shap at eros-os dot com>]

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.

>   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.

>  
> >   Coyotos doesn't have anything remotely like a signal. A depressing
> >   number of cross tools and libraries assume that this is available.
> 
>   Well, I don't know what you're referring to here, that's a very vague
> description of the problem.  Again, this problem is not insoluble, by
> providing wrappers and avoiding invoking the unimplemented functionality in
> your applications; see the way newlib provides libnosys stubs.

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().

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.
 
> > This is *very* frustrating. Both glibc and libstdc++ *used* to be
> > portable to non-UNIX systems. Somewhere along the way, that ceased to be
> > true.
> 
>   Surely they can never have been so portable as to build on a system that has
> no support in the config* and auto* framework?

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.

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.


shap


--
For unsubscribe information see http://sourceware.org/lists.html#faq