> Date: Wed, 22 Jun 2011 20:16:48 +0200
> From: Hans-Peter Nilsson
>
> PR47836
> PR23656
> PR47733
> PR49247
> * configure.ac (target_libraries): Remove target-libiberty.
...
JFTR, that's not proper PR annotation. I changed it as obvious
to the following, which en
> Ok for trunk?
Ok with me. I'll let the branch maintainers decide if they want it
for their branches.
> Date: Mon, 20 Jun 2011 16:58:41 + (UTC)
> From: "Joseph S. Myers"
> On Mon, 20 Jun 2011, Hans-Peter Nilsson wrote:
>
> > It seems none in approval capacity have any objection to
> > (figuratively) s/target-libiberty//g in toplevel/configure.ac on
> > all branches. Is an --enable-target-li
On Mon, 20 Jun 2011, Hans-Peter Nilsson wrote:
> It seems none in approval capacity have any objection to
> (figuratively) s/target-libiberty//g in toplevel/configure.ac on
> all branches. Is an --enable-target-libiberty or
> --with-target-libiberty needed? (I'd just rather not.)
There should b
On Wed, 18 May 2011, Joseph S. Myers wrote:
> On Wed, 18 May 2011, DJ Delorie wrote:
>
> > At this point, though, I'm tempted to say "there's no such thing as a
> > target libiberty" and rip all the target-libiberty rules out, and let
>
> Yes please. I've been arguing for that for some time.
>
> h
> > Since you feel so strongly about it and nobody objects, go ahead.
>
> Backport to open branches? (And note PR48825.)
I've already given my OK, it's up to the branch managers to apply as
they see fit.
On 08/06/11 12:56, Hans-Peter Nilsson wrote:
> On Thu, 26 May 2011, DJ Delorie wrote:
>>
>>> Yes please. I've been arguing for that for some time.
>>
>> Since you feel so strongly about it and nobody objects, go ahead.
>
> Backport to open branches? (And note PR48825.)
>
> brgds, H-P
>
>
I t
On Thu, 26 May 2011, DJ Delorie wrote:
>
> > Yes please. I've been arguing for that for some time.
>
> Since you feel so strongly about it and nobody objects, go ahead.
Backport to open branches? (And note PR48825.)
brgds, H-P
> Yes please. I've been arguing for that for some time.
Since you feel so strongly about it and nobody objects, go ahead.
> http://gcc.gnu.org/ml/gcc/2009-04/msg00410.html
> http://gcc.gnu.org/ml/gcc/2010-03/msg2.html
> http://gcc.gnu.org/ml/gcc/2010-03/msg00012.html
> http://gcc.gnu.org/ml
On Wed, 18 May 2011, DJ Delorie wrote:
> What about these?
>
> dependencies = { module=all-target-fastjar; on=all-target-libiberty; };
Bogus. fastjar is not a target module, not should it be one; all
references to target fastjar should be removed.
> dependencies = { module=all-target-libobjc;
What about these?
dependencies = { module=all-target-fastjar; on=all-target-libiberty; };
dependencies = { module=all-target-libobjc; on=all-target-libiberty; };
dependencies = { module=all-target-libstdc++-v3; on=all-target-libiberty; };
On Wed, 18 May 2011, DJ Delorie wrote:
> At this point, though, I'm tempted to say "there's no such thing as a
> target libiberty" and rip all the target-libiberty rules out, and let
Yes please. I've been arguing for that for some time.
http://gcc.gnu.org/ml/gcc/2009-04/msg00410.html
http://gcc
On May 18 14:03, DJ Delorie wrote:
>
> > And the problem is that libiberty is assuming that it *knows* what
> > functions newlib provides, so that it doesn't need to check
> > directly. This is just broken...
>
> Historically, cygwin was built using libiberty and newlib, so you did
> not have a
> And the problem is that libiberty is assuming that it *knows* what
> functions newlib provides, so that it doesn't need to check
> directly. This is just broken...
Historically, cygwin was built using libiberty and newlib, so you did
not have a runtime at the time you were building libiberty,
On Tue, 2011-05-17 at 12:48 -0400, DJ Delorie wrote:
> > What I don't understand is why the newlib change broke older compilers.
>
> Older compilers have the older libiberty. At the moment, libiberty
> cannot be built by *any* released gcc, because you cannot *build* any
> released gcc, because
> What I don't understand is why the newlib change broke older compilers.
Older compilers have the older libiberty. At the moment, libiberty
cannot be built by *any* released gcc, because you cannot *build* any
released gcc, because it cannot build its target libiberty.
> The function has been
> Thanks. I just have no check in rights to the gcc repository. I
> applied the change to the sourceware CVS repository but for gcc I
> need a proxy.
Please, never apply libiberty patches only to src. They're likely to
get deleted by the robomerge. The rule is: gcc only, or both at the
same t
> So regardless of whether the changes to newlib are a good idea or not, I
> think the fix to libiberty is still right.
Irrelevent. I said I'd accept that change *after* the real problem is
fixed. The real problem hasn't been fixed.
The real problem is that libibery should NOT INCLUDE PSIGNAL
On May 17 17:07, Richard Earnshaw wrote:
>
> On Tue, 2011-05-17 at 11:52 -0400, DJ Delorie wrote:
> > > > * strsignal.c (psignal): Change second parameter to const char
> > > > *.
> > > > Fix comment accordingly.
> > > >
> > >
> > > OK.
> >
> > I had argued against this patch:
On May 17 16:33, Richard Earnshaw wrote:
>
> On Thu, 2011-05-05 at 09:30 +0200, Corinna Vinschen wrote:
> > [Please keep me CCed, I'm not subscribed to gcc-patches. Thank you]
> >
> > Hi,
> >
> > the definition of psignal in libiberty is
> >
> >void psignal (int, char *);
> >
> > The corr
On Tue, 2011-05-17 at 11:52 -0400, DJ Delorie wrote:
> > > * strsignal.c (psignal): Change second parameter to const char *.
> > > Fix comment accordingly.
> > >
> >
> > OK.
>
> I had argued against this patch:
>
> http://gcc.gnu.org/ml/gcc-patches/2011-05/msg00439.html
>
> The newlib cha
> > * strsignal.c (psignal): Change second parameter to const char *.
> > Fix comment accordingly.
> >
>
> OK.
I had argued against this patch:
http://gcc.gnu.org/ml/gcc-patches/2011-05/msg00439.html
The newlib change broke ALL released versions of gcc, and the above
patch does NOT fi
On Thu, 2011-05-05 at 09:30 +0200, Corinna Vinschen wrote:
> [Please keep me CCed, I'm not subscribed to gcc-patches. Thank you]
>
> Hi,
>
> the definition of psignal in libiberty is
>
>void psignal (int, char *);
>
> The correct definition per POSIX is
>
>void psignal (int, const ch
On Thu, May 5, 2011 at 12:54 AM, Corinna Vinschen wrote:
> On May 5 00:40, Andrew Pinski wrote:
>> On Thu, May 5, 2011 at 12:30 AM, Corinna Vinschen
>> wrote:
>> > Thanks,
>> > Corinna
>> >
>> >
>> > * strsignal.c (psignal): Change second parameter to const char *.
>> > Fix commen
On May 5 00:40, Andrew Pinski wrote:
> On Thu, May 5, 2011 at 12:30 AM, Corinna Vinschen wrote:
> > Thanks,
> > Corinna
> >
> >
> > * strsignal.c (psignal): Change second parameter to const char *.
> > Fix comment accordingly.
>
>
> I don't think this is needed. What goes wrong w
On Thu, May 5, 2011 at 12:30 AM, Corinna Vinschen wrote:
> Thanks,
> Corinna
>
>
> * strsignal.c (psignal): Change second parameter to const char *.
> Fix comment accordingly.
I don't think this is needed. What goes wrong without it?
Thanks,
Andrew Pinski
26 matches
Mail list logo
