* Libiberty: POSIXify psignal definition @ 2011-05-05 7:39 Corinna Vinschen 2011-05-05 7:55 ` Andrew Pinski 2011-05-17 18:28 ` Richard Earnshaw 0 siblings, 2 replies; 27+ messages in thread From: Corinna Vinschen @ 2011-05-05 7:39 UTC (permalink / raw) To: gcc-patches [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 char *); The below patch fixes that. Thanks, Corinna * strsignal.c (psignal): Change second parameter to const char *. Fix comment accordingly. Index: strsignal.c =================================================================== RCS file: /cvs/src/src/libiberty/strsignal.c,v retrieving revision 1.11 diff -u -p -r1.11 strsignal.c --- strsignal.c 19 Jun 2008 15:17:56 -0000 1.11 +++ strsignal.c 5 May 2011 07:29:42 -0000 @@ -538,7 +538,7 @@ strtosigno (const char *name) /* -@deftypefn Supplemental void psignal (int @var{signo}, char *@var{message}) +@deftypefn Supplemental void psignal (int @var{signo}, const char *@var{message}) Print @var{message} to the standard error, followed by a colon, followed by the description of the signal specified by @var{signo}, @@ -551,7 +551,7 @@ followed by a newline. #ifndef HAVE_PSIGNAL void -psignal (int signo, char *message) +psignal (int signo, const char *message) { if (signal_names == NULL) { -- Corinna Vinschen Cygwin Project Co-Leader Red Hat ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Libiberty: POSIXify psignal definition 2011-05-05 7:39 Libiberty: POSIXify psignal definition Corinna Vinschen @ 2011-05-05 7:55 ` Andrew Pinski 2011-05-05 9:00 ` Corinna Vinschen 2011-05-17 18:28 ` Richard Earnshaw 1 sibling, 1 reply; 27+ messages in thread From: Andrew Pinski @ 2011-05-05 7:55 UTC (permalink / raw) To: Corinna Vinschen; +Cc: gcc-patches On Thu, May 5, 2011 at 12:30 AM, Corinna Vinschen <vinschen@redhat.com> 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Libiberty: POSIXify psignal definition 2011-05-05 7:55 ` Andrew Pinski @ 2011-05-05 9:00 ` Corinna Vinschen 2011-05-05 17:32 ` Andrew Pinski 0 siblings, 1 reply; 27+ messages in thread From: Corinna Vinschen @ 2011-05-05 9:00 UTC (permalink / raw) To: Andrew Pinski; +Cc: gcc-patches On May 5 00:40, Andrew Pinski wrote: > On Thu, May 5, 2011 at 12:30 AM, Corinna Vinschen <vinschen@redhat.com> 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? It's not about need, it's about correctness. It collides with the new, POSIXly correct declaration of psignal in newlib/libc/include/signal.h. Thanks, Corinna -- Corinna Vinschen Cygwin Project Co-Leader Red Hat ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Libiberty: POSIXify psignal definition 2011-05-05 9:00 ` Corinna Vinschen @ 2011-05-05 17:32 ` Andrew Pinski 0 siblings, 0 replies; 27+ messages in thread From: Andrew Pinski @ 2011-05-05 17:32 UTC (permalink / raw) To: Corinna Vinschen; +Cc: gcc-patches On Thu, May 5, 2011 at 12:54 AM, Corinna Vinschen <vinschen@redhat.com> wrote: > On May 5 00:40, Andrew Pinski wrote: >> On Thu, May 5, 2011 at 12:30 AM, Corinna Vinschen <vinschen@redhat.com> 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? > > It's not about need, it's about correctness. It collides with the new, > POSIXly correct declaration of psignal in newlib/libc/include/signal.h. But this could should not show up if psignal is declared. So it should not matter if it collides with that declaration. Thanks, Andrew Pinski ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Libiberty: POSIXify psignal definition 2011-05-05 7:39 Libiberty: POSIXify psignal definition Corinna Vinschen 2011-05-05 7:55 ` Andrew Pinski @ 2011-05-17 18:28 ` Richard Earnshaw 2011-05-17 18:32 ` DJ Delorie 2011-05-17 19:42 ` Corinna Vinschen 1 sibling, 2 replies; 27+ messages in thread From: Richard Earnshaw @ 2011-05-17 18:28 UTC (permalink / raw) To: Corinna Vinschen; +Cc: gcc-patches 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 char *); > > The below patch fixes that. > > > Thanks, > Corinna > > > * strsignal.c (psignal): Change second parameter to const char *. > Fix comment accordingly. > OK. R. ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Libiberty: POSIXify psignal definition 2011-05-17 18:28 ` Richard Earnshaw @ 2011-05-17 18:32 ` DJ Delorie 2011-05-17 19:34 ` Richard Earnshaw 2011-05-17 19:42 ` Corinna Vinschen 1 sibling, 1 reply; 27+ messages in thread From: DJ Delorie @ 2011-05-17 18:32 UTC (permalink / raw) To: Richard Earnshaw; +Cc: vinschen, gcc-patches > > * 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 fix the problem, but merely hides it until the next time we trip over it. ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Libiberty: POSIXify psignal definition 2011-05-17 18:32 ` DJ Delorie @ 2011-05-17 19:34 ` Richard Earnshaw 2011-05-17 19:47 ` Corinna Vinschen 2011-05-17 20:03 ` Libiberty: POSIXify psignal definition DJ Delorie 0 siblings, 2 replies; 27+ messages in thread From: Richard Earnshaw @ 2011-05-17 19:34 UTC (permalink / raw) To: DJ Delorie; +Cc: vinschen, gcc-patches 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 change broke ALL released versions of gcc, and the above > patch does NOT fix the problem, but merely hides it until the next > time we trip over it. > So regardless of whether the changes to newlib are a good idea or not, I think the fix to libiberty is still right. Posix says that psignal takes a const char *, and libiberty's implementation doesn't. That's just silly. I do agree that the newlib code should be tightened up, particularly in order to support older compilers; but that doesn't mean we shouldn't fix libiberty as well. R. ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Libiberty: POSIXify psignal definition 2011-05-17 19:34 ` Richard Earnshaw @ 2011-05-17 19:47 ` Corinna Vinschen 2011-05-18 0:15 ` DJ Delorie 2011-05-17 20:03 ` Libiberty: POSIXify psignal definition DJ Delorie 1 sibling, 1 reply; 27+ messages in thread From: Corinna Vinschen @ 2011-05-17 19:47 UTC (permalink / raw) To: Richard Earnshaw; +Cc: DJ Delorie, gcc-patches 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: > > > > 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 fix the problem, but merely hides it until the next > > time we trip over it. > > > > So regardless of whether the changes to newlib are a good idea or not, I > think the fix to libiberty is still right. Posix says that psignal takes > a const char *, and libiberty's implementation doesn't. That's just > silly. > > I do agree that the newlib code should be tightened up, particularly in > order to support older compilers; What I don't understand is why the newlib change broke older compilers. The function has been added to newlib and the definitions in newlib are correct. If this is refering to the fact that libiberty doesn't grok automatically if a symbol has been added to newlib, then that's a problem in libiberty, not in newlib. Otherwise, if you're building an older compiler, just use an older newlib as well. Corinna -- Corinna Vinschen Cygwin Project Co-Leader Red Hat ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Libiberty: POSIXify psignal definition 2011-05-17 19:47 ` Corinna Vinschen @ 2011-05-18 0:15 ` DJ Delorie 2011-05-18 18:38 ` Richard Earnshaw 0 siblings, 1 reply; 27+ messages in thread From: DJ Delorie @ 2011-05-18 0:15 UTC (permalink / raw) To: Corinna Vinschen; +Cc: rearnsha, gcc-patches > 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 added to newlib and the definitions in newlib are > correct. "Correct" is irrelevent. They don't match libiberty, so the build breaks. > If this is refering to the fact that libiberty doesn't grok > automatically if a symbol has been added to newlib, then that's a > problem in libiberty, not in newlib. It's a problem in every released gcc at the moment, so no released gcc can be built for a newlib target, without hacking the sources. > Otherwise, if you're building an older compiler, just use an older > newlib as well. The only option here is to not release a newlib at all until a fixed gcc release happens, then, and require that fixed gcc for that version of newlib forward. ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Libiberty: POSIXify psignal definition 2011-05-18 0:15 ` DJ Delorie @ 2011-05-18 18:38 ` Richard Earnshaw 2011-05-18 19:05 ` DJ Delorie 0 siblings, 1 reply; 27+ messages in thread From: Richard Earnshaw @ 2011-05-18 18:38 UTC (permalink / raw) To: DJ Delorie; +Cc: Corinna Vinschen, gcc-patches 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 it cannot build its target libiberty. > 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... # If we are being configured for newlib, we know which functions # newlib provide and which ones we will be expected to provide. ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Libiberty: POSIXify psignal definition 2011-05-18 18:38 ` Richard Earnshaw @ 2011-05-18 19:05 ` DJ Delorie 2011-05-18 19:27 ` Corinna Vinschen 2011-05-18 20:19 ` Joseph S. Myers 0 siblings, 2 replies; 27+ messages in thread From: DJ Delorie @ 2011-05-18 19:05 UTC (permalink / raw) To: Richard Earnshaw; +Cc: vinschen, gcc-patches > 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, because you hadn't built newlib yet. In a combined tree, target-libiberty is still built before target-newlib, so the problem exists there too. 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 newlib-hosted targets autodetect the host-libiberty. That is, if Cygwin doesn't need a target-libiberty any more? ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Libiberty: POSIXify psignal definition 2011-05-18 19:05 ` DJ Delorie @ 2011-05-18 19:27 ` Corinna Vinschen 2011-05-18 20:19 ` Joseph S. Myers 1 sibling, 0 replies; 27+ messages in thread From: Corinna Vinschen @ 2011-05-18 19:27 UTC (permalink / raw) To: DJ Delorie; +Cc: Richard Earnshaw, gcc-patches 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 runtime at the time you were building libiberty, because > you hadn't built newlib yet. > > In a combined tree, target-libiberty is still built before > target-newlib, so the problem exists there too. > > 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 > newlib-hosted targets autodetect the host-libiberty. That is, if > Cygwin doesn't need a target-libiberty any more? Cygwin doesn't need libiberty anymore since 2007. Corinna -- Corinna Vinschen Cygwin Project Co-Leader Red Hat ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Libiberty: POSIXify psignal definition 2011-05-18 19:05 ` DJ Delorie 2011-05-18 19:27 ` Corinna Vinschen @ 2011-05-18 20:19 ` Joseph S. Myers 2011-05-18 20:26 ` DJ Delorie ` (2 more replies) 1 sibling, 3 replies; 27+ messages in thread From: Joseph S. Myers @ 2011-05-18 20:19 UTC (permalink / raw) To: DJ Delorie; +Cc: Richard Earnshaw, vinschen, gcc-patches 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.gnu.org/ml/gcc/2010-03/msg00002.html http://gcc.gnu.org/ml/gcc/2010-03/msg00012.html http://gcc.gnu.org/ml/gcc-patches/2010-12/msg01231.html http://gcc.gnu.org/ml/gcc-bugs/2011-03/msg00206.html http://gcc.gnu.org/ml/gcc/2011-03/msg00465.html http://gcc.gnu.org/ml/gcc-patches/2011-03/msg02304.html -- Joseph S. Myers joseph@codesourcery.com ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Libiberty: POSIXify psignal definition 2011-05-18 20:19 ` Joseph S. Myers @ 2011-05-18 20:26 ` DJ Delorie 2011-05-18 20:31 ` Joseph S. Myers 2011-05-26 16:46 ` DJ Delorie 2011-06-20 16:57 ` Removing target-libiberty (was: Re: Libiberty: POSIXify psignal definition) Hans-Peter Nilsson 2 siblings, 1 reply; 27+ messages in thread From: DJ Delorie @ 2011-05-18 20:26 UTC (permalink / raw) To: Joseph S. Myers; +Cc: rearnsha, vinschen, gcc-patches 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; }; ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Libiberty: POSIXify psignal definition 2011-05-18 20:26 ` DJ Delorie @ 2011-05-18 20:31 ` Joseph S. Myers 0 siblings, 0 replies; 27+ messages in thread From: Joseph S. Myers @ 2011-05-18 20:31 UTC (permalink / raw) To: DJ Delorie; +Cc: rearnsha, vinschen, gcc-patches 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; on=all-target-libiberty; }; Bogus. libobjc makes no use of libiberty. > dependencies = { module=all-target-libstdc++-v3; on=all-target-libiberty; }; Bogus. libstdc++ uses cp-demangle.c from the libiberty source directory via special makefile rules; it makes no other use of libiberty and does not use a target libiberty.a, only that source file. -- Joseph S. Myers joseph@codesourcery.com ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Libiberty: POSIXify psignal definition 2011-05-18 20:19 ` Joseph S. Myers 2011-05-18 20:26 ` DJ Delorie @ 2011-05-26 16:46 ` DJ Delorie 2011-06-08 12:21 ` Hans-Peter Nilsson 2011-06-20 16:57 ` Removing target-libiberty (was: Re: Libiberty: POSIXify psignal definition) Hans-Peter Nilsson 2 siblings, 1 reply; 27+ messages in thread From: DJ Delorie @ 2011-05-26 16:46 UTC (permalink / raw) To: Joseph S. Myers; +Cc: gcc-patches > 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/msg00002.html > http://gcc.gnu.org/ml/gcc/2010-03/msg00012.html > http://gcc.gnu.org/ml/gcc-patches/2010-12/msg01231.html > http://gcc.gnu.org/ml/gcc-bugs/2011-03/msg00206.html > http://gcc.gnu.org/ml/gcc/2011-03/msg00465.html > http://gcc.gnu.org/ml/gcc-patches/2011-03/msg02304.html ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Libiberty: POSIXify psignal definition 2011-05-26 16:46 ` DJ Delorie @ 2011-06-08 12:21 ` Hans-Peter Nilsson 2011-06-08 13:12 ` Richard Earnshaw 2011-06-08 14:09 ` DJ Delorie 0 siblings, 2 replies; 27+ messages in thread From: Hans-Peter Nilsson @ 2011-06-08 12:21 UTC (permalink / raw) To: DJ Delorie; +Cc: Joseph S. Myers, gcc-patches 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Libiberty: POSIXify psignal definition 2011-06-08 12:21 ` Hans-Peter Nilsson @ 2011-06-08 13:12 ` Richard Earnshaw 2011-06-08 14:09 ` DJ Delorie 1 sibling, 0 replies; 27+ messages in thread From: Richard Earnshaw @ 2011-06-08 13:12 UTC (permalink / raw) To: Hans-Peter Nilsson; +Cc: DJ Delorie, Joseph S. Myers, gcc-patches 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 think we have to, given that at present this breaks building older compilers with newer versions of newlib. R. ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Libiberty: POSIXify psignal definition 2011-06-08 12:21 ` Hans-Peter Nilsson 2011-06-08 13:12 ` Richard Earnshaw @ 2011-06-08 14:09 ` DJ Delorie 1 sibling, 0 replies; 27+ messages in thread From: DJ Delorie @ 2011-06-08 14:09 UTC (permalink / raw) To: Hans-Peter Nilsson; +Cc: gcc-patches > > 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. ^ permalink raw reply [flat|nested] 27+ messages in thread
* Removing target-libiberty (was: Re: Libiberty: POSIXify psignal definition) 2011-05-18 20:19 ` Joseph S. Myers 2011-05-18 20:26 ` DJ Delorie 2011-05-26 16:46 ` DJ Delorie @ 2011-06-20 16:57 ` Hans-Peter Nilsson 2011-06-20 17:03 ` Joseph S. Myers 2 siblings, 1 reply; 27+ messages in thread From: Hans-Peter Nilsson @ 2011-06-20 16:57 UTC (permalink / raw) To: Joseph S. Myers; +Cc: DJ Delorie, Richard Earnshaw, vinschen, gcc-patches 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. > > http://gcc.gnu.org/ml/gcc/2009-04/msg00410.html > http://gcc.gnu.org/ml/gcc/2010-03/msg00002.html > http://gcc.gnu.org/ml/gcc/2010-03/msg00012.html > http://gcc.gnu.org/ml/gcc-patches/2010-12/msg01231.html > http://gcc.gnu.org/ml/gcc-bugs/2011-03/msg00206.html > http://gcc.gnu.org/ml/gcc/2011-03/msg00465.html > http://gcc.gnu.org/ml/gcc-patches/2011-03/msg02304.html I thought you had the ball on this, but I don't see anything happened since the above was written. I could just add clauses for my own targets, but I want this to happen, so I'll pick it up if it's on the floor. 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.) What would be an approvable test procedure? Is it enough to test it on native x86_64-linux and cris-axis-elf (a newlib target) with old and new/breaking newlib? At a glance this would partially fix PR47836, and completely fix PR23656, PR47733, PR49247. brgds, H-P ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Removing target-libiberty (was: Re: Libiberty: POSIXify psignal definition) 2011-06-20 16:57 ` Removing target-libiberty (was: Re: Libiberty: POSIXify psignal definition) Hans-Peter Nilsson @ 2011-06-20 17:03 ` Joseph S. Myers 2011-06-22 18:44 ` Hans-Peter Nilsson 0 siblings, 1 reply; 27+ messages in thread From: Joseph S. Myers @ 2011-06-20 17:03 UTC (permalink / raw) To: Hans-Peter Nilsson; +Cc: DJ Delorie, Richard Earnshaw, vinschen, gcc-patches 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 be no such option. It should just be a matter of removing "target_modules = { module= libiberty; };" and everything that references target-libiberty. -- Joseph S. Myers joseph@codesourcery.com ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Removing target-libiberty (was: Re: Libiberty: POSIXify psignal definition) 2011-06-20 17:03 ` Joseph S. Myers @ 2011-06-22 18:44 ` Hans-Peter Nilsson 2011-06-22 19:37 ` DJ Delorie 2011-06-22 21:40 ` Hans-Peter Nilsson 0 siblings, 2 replies; 27+ messages in thread From: Hans-Peter Nilsson @ 2011-06-22 18:44 UTC (permalink / raw) To: gcc-patches; +Cc: dj, rearnsha, vinschen, joseph > Date: Mon, 20 Jun 2011 16:58:41 +0000 (UTC) > From: "Joseph S. Myers" <joseph@codesourcery.com> > 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 be no such option. It should just be a matter of removing > "target_modules = { module= libiberty; };" and everything that references > target-libiberty. Here we go, pretty straightforward. For lack of other suggestions, tested as I suggested: native x86_64-unknown-linux-gnu, cross to cris-axis-elf, both with old and new ("breaking") newlib. Note that I didn't (have to) change libiberty; after this patch there'll be dead code for target-libiberty ripe for cleanup. There's a rationale in <http://gcc.gnu.org/ml/gcc-patches/2011-05/msg01311.html> for where Joseph mentions some of the bogus dependencies; Looking at winsup ISTM it's the same (not a *target* dependency, but a *host* dependency; like a cross-compiler it's built using host tools and libraries, not using the newly built target tools and libraries). Ok for trunk? Patch for branches will look slightly different; the code in configure.ac was a single chunk thanks to Joseph breaking it out earlier. (Pre-approvals welcome. :) PR47836 PR23656 PR47733 PR49247 * configure.ac (target_libraries): Remove target-libiberty. Remove case-statement setting skipdirs=target-libiberty for multiple targets. Remove checking target_configdirs and removing target-libiberty but keeping target-libgcc if otherwise empty. * Makefile.def (target_modules): Don't add libiberty. (dependencies): Remove all traces of target-libiberty. * configure, Makefile.in: Regenerate. Index: configure.ac =================================================================== --- configure.ac (revision 175272) +++ configure.ac (working copy) @@ -149,9 +149,8 @@ libgcj="target-libffi \ # these libraries are built for the target environment, and are built after # the host libraries and the host tools (which may be a cross compiler) -# +# Note that libiberty is not a target library. target_libraries="target-libgcc \ - target-libiberty \ target-libgloss \ target-newlib \ target-libgomp \ @@ -490,51 +489,6 @@ case "${target}" in ;; esac -# Disable target libiberty for some systems. -case "${target}" in - *-*-kaos*) - # Remove unsupported stuff on all kaOS configurations. - skipdirs="target-libiberty" - ;; - *-*-netbsd*) - # Skip some stuff on all NetBSD configurations. - noconfigdirs="$noconfigdirs target-libiberty" - ;; - *-*-netware*) - noconfigdirs="$noconfigdirs target-libiberty" - ;; - *-*-rtems*) - skipdirs="${skipdirs} target-libiberty" - ;; - *-*-tpf*) - noconfigdirs="$noconfigdirs target-libiberty" - ;; - *-*-vxworks*) - noconfigdirs="$noconfigdirs target-libiberty" - ;; - sh*-*-pe|mips*-*-pe|*arm-wince-pe) - noconfigdirs="$noconfigdirs target-libiberty" - ;; - arm*-*-symbianelf*|arm*-*-linux-androideabi) - noconfigdirs="$noconfigdirs target-libiberty" - ;; - avr-*-*) - noconfigdirs="$noconfigdirs target-libiberty" - ;; - m68hc11-*-*|m6811-*-*|m68hc12-*-*|m6812-*-*) - noconfigdirs="$noconfigdirs target-libiberty" - ;; - picochip-*-*) - noconfigdirs="$noconfigdirs target-libiberty" - ;; - mips*-sde-elf*) - skipdirs="$skipdirs target-libiberty" - ;; - ip2k-*-*) - noconfigdirs="$noconfigdirs target-libiberty" - ;; -esac - # Disable libstdc++-v3 for some systems. case "${target}" in *-*-vxworks*) @@ -1965,27 +1919,6 @@ for dir in . $skipdirs $noconfigdirs ; d fi done -# Sometimes the tools are distributed with libiberty but with no other -# libraries. In that case, we don't want to build target-libiberty. -# Don't let libgcc imply libiberty either. -if test -n "${target_configdirs}" ; then - libgcc= - others= - for i in `echo ${target_configdirs} | sed -e s/target-//g` ; do - if test "$i" = "libgcc"; then - libgcc=target-libgcc - elif test "$i" != "libiberty" ; then - if test -r $srcdir/$i/configure ; then - others=yes; - break; - fi - fi - done - if test -z "${others}" ; then - target_configdirs=$libgcc - fi -fi - # Quietly strip out all directories which aren't configurable in this tree. # This relies on all configurable subdirectories being autoconfiscated, which # is now the case. Index: Makefile.def =================================================================== --- Makefile.def (revision 175272) +++ Makefile.def (working copy) @@ -131,7 +131,6 @@ target_modules = { module= libtermcap; n missing=maintainer-clean; }; target_modules = { module= winsup; }; target_modules = { module= libgloss; no_check=true; }; -target_modules = { module= libiberty; }; target_modules = { module= libffi; }; target_modules = { module= libjava; raw_cxx=true; }; target_modules = { module= zlib; }; @@ -481,7 +480,6 @@ lang_env_dependencies = { module=libiber dependencies = { module=configure-target-boehm-gc; on=all-target-libstdc++-v3; }; dependencies = { module=configure-target-fastjar; on=configure-target-zlib; }; dependencies = { module=all-target-fastjar; on=all-target-zlib; }; -dependencies = { module=all-target-fastjar; on=all-target-libiberty; }; dependencies = { module=configure-target-libgo; on=configure-target-libffi; }; dependencies = { module=configure-target-libgo; on=all-target-libstdc++-v3; }; dependencies = { module=all-target-libgo; on=all-target-libffi; }; @@ -493,9 +491,7 @@ dependencies = { module=all-target-libja dependencies = { module=all-target-libjava; on=all-target-boehm-gc; }; dependencies = { module=all-target-libjava; on=all-target-libffi; }; dependencies = { module=configure-target-libobjc; on=configure-target-boehm-gc; }; -dependencies = { module=all-target-libobjc; on=all-target-libiberty; }; dependencies = { module=all-target-libobjc; on=all-target-boehm-gc; }; -dependencies = { module=all-target-libstdc++-v3; on=all-target-libiberty; }; dependencies = { module=configure-target-libstdc++-v3; on=configure-target-libgomp; }; // parallel_list.o and parallel_settings.o depend on omp.h, which is // generated by the libgomp configure. Unfortunately, due to the use of @@ -508,10 +504,7 @@ lang_env_dependencies = { module=rda; }; lang_env_dependencies = { module=winsup; }; dependencies = { module=all-target-libgloss; on=all-target-newlib; }; -dependencies = { module=all-target-winsup; on=all-target-libiberty; }; dependencies = { module=all-target-winsup; on=all-target-libtermcap; }; -dependencies = { module=configure-target-libiberty; on=all-binutils; }; -dependencies = { module=configure-target-libiberty; on=all-ld; }; dependencies = { module=configure-target-newlib; on=all-binutils; }; dependencies = { module=configure-target-newlib; on=all-ld; }; dependencies = { module=configure-target-libgfortran; on=all-target-libquadmath; }; brgds, H-P ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Removing target-libiberty (was: Re: Libiberty: POSIXify psignal definition) 2011-06-22 18:44 ` Hans-Peter Nilsson @ 2011-06-22 19:37 ` DJ Delorie 2011-06-22 21:40 ` Hans-Peter Nilsson 1 sibling, 0 replies; 27+ messages in thread From: DJ Delorie @ 2011-06-22 19:37 UTC (permalink / raw) To: Hans-Peter Nilsson; +Cc: gcc-patches, rearnsha, vinschen, joseph > Ok for trunk? Ok with me. I'll let the branch maintainers decide if they want it for their branches. ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Removing target-libiberty (was: Re: Libiberty: POSIXify psignal definition) 2011-06-22 18:44 ` Hans-Peter Nilsson 2011-06-22 19:37 ` DJ Delorie @ 2011-06-22 21:40 ` Hans-Peter Nilsson 1 sibling, 0 replies; 27+ messages in thread From: Hans-Peter Nilsson @ 2011-06-22 21:40 UTC (permalink / raw) To: gcc-patches > Date: Wed, 22 Jun 2011 20:16:48 +0200 > From: Hans-Peter Nilsson <hp@axis.com> > > 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 ends up as intended in bugzilla. PR regression/47836 PR bootstrap/23656 PR other/47733 PR bootstrap/49247 * configure.ac (target_libraries): Remove target-libiberty. ... brgds, H-P ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Libiberty: POSIXify psignal definition 2011-05-17 19:34 ` Richard Earnshaw 2011-05-17 19:47 ` Corinna Vinschen @ 2011-05-17 20:03 ` DJ Delorie 1 sibling, 0 replies; 27+ messages in thread From: DJ Delorie @ 2011-05-17 20:03 UTC (permalink / raw) To: Richard Earnshaw; +Cc: vinschen, gcc-patches > 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 AT ALL if newlib has it. What *should* have happened, is libiberty should have been fixed *first*, and newlib waited until a gcc/binutils release cycle happened, so that at least ONE version of those could build with newlib. ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Libiberty: POSIXify psignal definition 2011-05-17 18:28 ` Richard Earnshaw 2011-05-17 18:32 ` DJ Delorie @ 2011-05-17 19:42 ` Corinna Vinschen 2011-05-17 21:23 ` DJ Delorie 1 sibling, 1 reply; 27+ messages in thread From: Corinna Vinschen @ 2011-05-17 19:42 UTC (permalink / raw) To: gcc-patches; +Cc: Richard Earnshaw 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 correct definition per POSIX is > > > > void psignal (int, const char *); > > > > The below patch fixes that. > > > > > > Thanks, > > Corinna > > > > > > * strsignal.c (psignal): Change second parameter to const char *. > > Fix comment accordingly. > > > > OK. > > R. 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. Thanks, Corinna -- Corinna Vinschen Cygwin Project Co-Leader Red Hat ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Libiberty: POSIXify psignal definition 2011-05-17 19:42 ` Corinna Vinschen @ 2011-05-17 21:23 ` DJ Delorie 0 siblings, 0 replies; 27+ messages in thread From: DJ Delorie @ 2011-05-17 21:23 UTC (permalink / raw) To: Corinna Vinschen; +Cc: gcc-patches, rearnsha > 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 time. ^ permalink raw reply [flat|nested] 27+ messages in thread
end of thread, other threads:[~2011-06-22 20:58 UTC | newest] Thread overview: 27+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2011-05-05 7:39 Libiberty: POSIXify psignal definition Corinna Vinschen 2011-05-05 7:55 ` Andrew Pinski 2011-05-05 9:00 ` Corinna Vinschen 2011-05-05 17:32 ` Andrew Pinski 2011-05-17 18:28 ` Richard Earnshaw 2011-05-17 18:32 ` DJ Delorie 2011-05-17 19:34 ` Richard Earnshaw 2011-05-17 19:47 ` Corinna Vinschen 2011-05-18 0:15 ` DJ Delorie 2011-05-18 18:38 ` Richard Earnshaw 2011-05-18 19:05 ` DJ Delorie 2011-05-18 19:27 ` Corinna Vinschen 2011-05-18 20:19 ` Joseph S. Myers 2011-05-18 20:26 ` DJ Delorie 2011-05-18 20:31 ` Joseph S. Myers 2011-05-26 16:46 ` DJ Delorie 2011-06-08 12:21 ` Hans-Peter Nilsson 2011-06-08 13:12 ` Richard Earnshaw 2011-06-08 14:09 ` DJ Delorie 2011-06-20 16:57 ` Removing target-libiberty (was: Re: Libiberty: POSIXify psignal definition) Hans-Peter Nilsson 2011-06-20 17:03 ` Joseph S. Myers 2011-06-22 18:44 ` Hans-Peter Nilsson 2011-06-22 19:37 ` DJ Delorie 2011-06-22 21:40 ` Hans-Peter Nilsson 2011-05-17 20:03 ` Libiberty: POSIXify psignal definition DJ Delorie 2011-05-17 19:42 ` Corinna Vinschen 2011-05-17 21:23 ` DJ Delorie
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).