Libiberty: POSIXify psignal definition

Libiberty: POSIXify psignal definition

[Corinna Vinschen]

[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

Re: Libiberty: POSIXify psignal definition

[Andrew Pinski]

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

Re: Libiberty: POSIXify psignal definition

[Corinna Vinschen]

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

Re: Libiberty: POSIXify psignal definition

[Andrew Pinski]

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

Re: Libiberty: POSIXify psignal definition

[Richard Earnshaw]

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.

Re: Libiberty: POSIXify psignal definition

[DJ Delorie]

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

Re: Libiberty: POSIXify psignal definition

[Richard Earnshaw]

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.

Re: Libiberty: POSIXify psignal definition

[Corinna Vinschen]

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

Re: Libiberty: POSIXify psignal definition

[DJ Delorie]

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

Re: Libiberty: POSIXify psignal definition

[Richard Earnshaw]

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.

Re: Libiberty: POSIXify psignal definition

[DJ Delorie]

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

Re: Libiberty: POSIXify psignal definition

[Corinna Vinschen]

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

Re: Libiberty: POSIXify psignal definition

[Joseph S. Myers]

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

Re: Libiberty: POSIXify psignal definition

[DJ Delorie]

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; };

Re: Libiberty: POSIXify psignal definition

[Joseph S. Myers]

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

Re: Libiberty: POSIXify psignal definition

[DJ Delorie]

> 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

Re: Libiberty: POSIXify psignal definition

[Hans-Peter Nilsson]

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

Re: Libiberty: POSIXify psignal definition

[Richard Earnshaw]

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.

Re: Libiberty: POSIXify psignal definition

[DJ Delorie]

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

Removing target-libiberty (was: Re: Libiberty: POSIXify psignal definition)

[Hans-Peter Nilsson]

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

Re: Removing target-libiberty (was: Re: Libiberty: POSIXify psignal definition)

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

Re: Removing target-libiberty (was: Re: Libiberty: POSIXify psignal definition)

[Hans-Peter Nilsson]

> 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

Re: Removing target-libiberty (was: Re: Libiberty: POSIXify psignal definition)

[DJ Delorie]

> Ok for trunk?

Ok with me.  I'll let the branch maintainers decide if they want it
for their branches.

Re: Removing target-libiberty (was: Re: Libiberty: POSIXify psignal definition)

[Hans-Peter Nilsson]

> 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

Re: Libiberty: POSIXify psignal definition

[DJ Delorie]

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

Re: Libiberty: POSIXify psignal definition

[Corinna Vinschen]

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

Re: Libiberty: POSIXify psignal definition

[DJ Delorie]

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