On Mon, 1 Mar 2010, DJ Delorie wrote:
> > But I've previously noted that target libiberty seems completely useless;
>
> It's a target library, like newlib, libz, libstdc++, or anything else.
> How do you know there are no target applications that want to link
> against it?
GCC target libraries
> Is it still used outside the "Cygnus tree"?
How should I know? I don't know what users of free software do with
it...
It's a target library. Anyone writing code for any target might use
it.
On 03/01/2010 09:48 PM, DJ Delorie wrote:
But I've previously noted that target libiberty seems completely useless;
It's a target library, like newlib, libz, libstdc++, or anything else.
How do you know there are no target applications that want to link
against it?
Is it still used outside th
> But I've previously noted that target libiberty seems completely useless;
It's a target library, like newlib, libz, libstdc++, or anything else.
How do you know there are no target applications that want to link
against it?
On Mon, 1 Mar 2010, Jack Howarth wrote:
> Somehow the recursive make is broken for libiberty and is silently using
> the system compiler.
> Jack
I believe this is PR29404. IIRC, in addition to libiberty, other
recursive "make check"s fail too due to using the system (stage1)
compil
On Mon, Mar 01, 2010 at 02:31:52AM +0100, Andreas Schwab wrote:
> Jack Howarth writes:
>
> >While looking at PR42308 and trying to understand why the make check
> > is leaky and starts to call the system compiler instead of the xgcc during
> > a make check on either x86_64-apple-darwin9 or i6
On Mon, 1 Mar 2010, Andreas Schwab wrote:
> Jack Howarth writes:
>
> >While looking at PR42308 and trying to understand why the make check
> > is leaky and starts to call the system compiler instead of the xgcc during
> > a make check on either x86_64-apple-darwin9 or i686-apple-darwin10, I
Jack Howarth writes:
>While looking at PR42308 and trying to understand why the make check
> is leaky and starts to call the system compiler instead of the xgcc during
> a make check on either x86_64-apple-darwin9 or i686-apple-darwin10, I noticed
> that we seem to build libiberty both at the
While looking at PR42308 and trying to understand why the make check
is leaky and starts to call the system compiler instead of the xgcc during
a make check on either x86_64-apple-darwin9 or i686-apple-darwin10, I noticed
that we seem to build libiberty both at the toplevel and within the multil
