public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
* gcc-4_2-branch: tiny issue with libiberty
@ 2007-11-13  8:42 Thomas Schwinge
  2007-11-13  9:25 ` DJ Delorie
  2007-11-19 10:06 ` Ben Elliston
  0 siblings, 2 replies; 8+ messages in thread
From: Thomas Schwinge @ 2007-11-13  8:42 UTC (permalink / raw)
  To: gcc-patches

[-- Attachment #1: Type: text/plain, Size: 672 bytes --]

Hello!

On a build of the gcc-4_2-branch I noticed a tiny problem with libiberty,
which the following patch fixes.  Could this please be applied to
gcc-4_2-branch and trunk?


#v+
2007-11-13  Thomas Schwinge  <tschwinge@gnu.org>

	* strsignal.c (psignal): Adjust parameters to the declaration.

Index: strsignal.c
===================================================================
--- strsignal.c	(Revision 130085)
+++ strsignal.c	(Arbeitskopie)
@@ -549,7 +549,7 @@
 #ifndef HAVE_PSIGNAL
 
 void
-psignal (unsigned signo, char *message)
+psignal (int signo, const char *message)
 {
   if (signal_names == NULL)
     {
#v-


Regards,
 Thomas

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 191 bytes --]

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: gcc-4_2-branch: tiny issue with libiberty
  2007-11-13  8:42 gcc-4_2-branch: tiny issue with libiberty Thomas Schwinge
@ 2007-11-13  9:25 ` DJ Delorie
  2007-11-13 14:02   ` Thomas Schwinge
  2007-11-19 10:06 ` Ben Elliston
  1 sibling, 1 reply; 8+ messages in thread
From: DJ Delorie @ 2007-11-13  9:25 UTC (permalink / raw)
  To: tschwinge; +Cc: gcc-patches


> 	* strsignal.c (psignal): Adjust parameters to the declaration.

Which declaration?

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: gcc-4_2-branch: tiny issue with libiberty
  2007-11-13  9:25 ` DJ Delorie
@ 2007-11-13 14:02   ` Thomas Schwinge
  2007-11-13 14:37     ` DJ Delorie
  0 siblings, 1 reply; 8+ messages in thread
From: Thomas Schwinge @ 2007-11-13 14:02 UTC (permalink / raw)
  To: DJ Delorie; +Cc: gcc-patches

[-- Attachment #1: Type: text/plain, Size: 1622 bytes --]

Hello!

On Mon, Nov 12, 2007 at 09:16:21PM -0500, DJ Delorie wrote:
> > 	* strsignal.c (psignal): Adjust parameters to the declaration.
> 
> Which declaration?

OK, that ChangeLog comment was not the best one possible, I agree...

#v+
$ info libc Signal\ Messages
[...]
 -- Function: void psignal (int SIGNUM, const char *MESSAGE)
[...]
     This function is a BSD feature, declared in the header file
     `signal.h'.
[...]
$ echo '#include <signal.h>' | gcc -x c -o - -E - | grep psignal
extern void psignal (int __sig, __const char *__s);
#v-

Same for ``man psignal''.


Here is a better patch.  (It was late last night...)

#v+
2007-11-13  Thomas Schwinge  <tschwinge@gnu.org>

	* strsignal.c (psignal): Adjust comment and parameters to what is
	used in BSD systems.

Index: strsignal.c
===================================================================
--- strsignal.c	(Revision 130136)
+++ strsignal.c	(Arbeitskopie)
@@ -536,7 +536,7 @@
 
 /*
 
-@deftypefn Supplemental void psignal (unsigned @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},
@@ -549,7 +549,7 @@
 #ifndef HAVE_PSIGNAL
 
 void
-psignal (unsigned signo, char *message)
+psignal (int signo, const char *message)
 {
   if (signal_names == NULL)
     {
#v-


Someone then also needs to regenerate the `functions.texi' file.  Shall I
also submit a patch for that one?


Regards,
 Thomas

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 191 bytes --]

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: gcc-4_2-branch: tiny issue with libiberty
  2007-11-13 14:02   ` Thomas Schwinge
@ 2007-11-13 14:37     ` DJ Delorie
  2007-11-13 16:29       ` Thomas Schwinge
  0 siblings, 1 reply; 8+ messages in thread
From: DJ Delorie @ 2007-11-13 14:37 UTC (permalink / raw)
  To: tschwinge; +Cc: gcc-patches


>      This function is a BSD feature, declared in the header file
>      `signal.h'.

If you're using BSD, you already have psignal() and won't be (or
shouldn't be) using the one in libiberty, so the prototype doesn't
need to match.

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: gcc-4_2-branch: tiny issue with libiberty
  2007-11-13 14:37     ` DJ Delorie
@ 2007-11-13 16:29       ` Thomas Schwinge
  2007-11-13 16:43         ` DJ Delorie
  0 siblings, 1 reply; 8+ messages in thread
From: Thomas Schwinge @ 2007-11-13 16:29 UTC (permalink / raw)
  To: DJ Delorie; +Cc: gcc-patches

[-- Attachment #1: Type: text/plain, Size: 1069 bytes --]

Hello!

On Tue, Nov 13, 2007 at 09:02:02AM -0500, DJ Delorie wrote:
> >      This function is a BSD feature, declared in the header file
> >      `signal.h'.
> 
> If you're using BSD, you already have psignal() and won't be (or
> shouldn't be) using the one in libiberty, so the prototype doesn't
> need to match.

I'm not using a BSD system.  I only quoted where the function was
originating from.

The error for me showed up when building a cross compiler to a
glibc-based system.  I will try to investigate why the libiberty
configure machinery failed to detect the `psignal' symbol from the
target's glibc, which should have included that symbol.  The error showed
up, because the target glibc's <signal.h> header had been included and
thus its `psignal' declaration didn't match the libiberty `psignal'
definition.


Nevertheless, I don't understand why you don't want to adapt the
parameters to what other systems (glibc, BSD) are using?  Why should
libiberty provide a (marginally) different version of `psignal'?


Regards,
 Thomas

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 191 bytes --]

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: gcc-4_2-branch: tiny issue with libiberty
  2007-11-13 16:29       ` Thomas Schwinge
@ 2007-11-13 16:43         ` DJ Delorie
  2007-11-17 17:35           ` Thomas Schwinge
  0 siblings, 1 reply; 8+ messages in thread
From: DJ Delorie @ 2007-11-13 16:43 UTC (permalink / raw)
  To: tschwinge; +Cc: gcc-patches


> Nevertheless, I don't understand why you don't want to adapt the
> parameters to what other systems (glibc, BSD) are using?  Why should
> libiberty provide a (marginally) different version of `psignal'?

Well, for starters, it helps us find build problems like yours :-)

(I'm a big fan of choosing "fail loudly" over "fail quietly")

Since our psignal should only get used on platforms without their own
psignal, why does it matter?

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: gcc-4_2-branch: tiny issue with libiberty
  2007-11-13 16:43         ` DJ Delorie
@ 2007-11-17 17:35           ` Thomas Schwinge
  0 siblings, 0 replies; 8+ messages in thread
From: Thomas Schwinge @ 2007-11-17 17:35 UTC (permalink / raw)
  To: DJ Delorie; +Cc: gcc-patches, Roland McGrath

[-- Attachment #1: Type: text/plain, Size: 1653 bytes --]

[Roland: for your information.]


Hello!

On Tue, Nov 13, 2007 at 10:58:30AM -0500, DJ Delorie wrote:
> > Nevertheless, I don't understand why you don't want to adapt the
> > parameters to what other systems (glibc, BSD) are using?  Why should
> > libiberty provide a (marginally) different version of `psignal'?
> 
> Well, for starters, it helps us find build problems like yours :-)
> 
> (I'm a big fan of choosing "fail loudly" over "fail quietly")

I absolutely agree to ``failing loudly'' instead of ``failing quietly'',
however I think that this is a non-argument for the issue at hand here,
as it only triggered, because that one prototype (of GNU libc's and BSD
libc's `psignal') happened to be different from the libiberty
implementation.  Or do you want to suggest that you're going to introduce
such function signature changes for every libiberty-provided symbol?  I
hope you don't.  :-)


> Since our psignal should only get used on platforms without their own
> psignal, why does it matter?

So that the next person to see through this part of the libiberty sources
doesn't wonder why the libiberty `psignal' is (marginally) different from
the GNU libc or BSD libc one.  I still uphold that my patch should be
installed, but that's not for me to decide, obviously.


As for the original report: this was while building a i586-pc-gnu cross
compiler from the gcc-4_2-branch sources.  I can't reproduce the original
problem anymore and already lost the previous `config.log' file.  I
suspect it was a bogon resulting from a stale `config.cache' file and
change in the target's libc.


Regards,
 Thomas

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 191 bytes --]

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: gcc-4_2-branch: tiny issue with libiberty
  2007-11-13  8:42 gcc-4_2-branch: tiny issue with libiberty Thomas Schwinge
  2007-11-13  9:25 ` DJ Delorie
@ 2007-11-19 10:06 ` Ben Elliston
  1 sibling, 0 replies; 8+ messages in thread
From: Ben Elliston @ 2007-11-19 10:06 UTC (permalink / raw)
  To: Thomas Schwinge; +Cc: gcc-patches, dj

On Tue, 2007-11-13 at 02:51 +0100, Thomas Schwinge wrote:

> On a build of the gcc-4_2-branch I noticed a tiny problem with libiberty,
> which the following patch fixes.  Could this please be applied to
> gcc-4_2-branch and trunk?

I committed a fix to libiberty shortly after GCC branched for 4.2.  See
revision r121364.

Cheers, Ben


^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2007-11-18 23:51 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2007-11-13  8:42 gcc-4_2-branch: tiny issue with libiberty Thomas Schwinge
2007-11-13  9:25 ` DJ Delorie
2007-11-13 14:02   ` Thomas Schwinge
2007-11-13 14:37     ` DJ Delorie
2007-11-13 16:29       ` Thomas Schwinge
2007-11-13 16:43         ` DJ Delorie
2007-11-17 17:35           ` Thomas Schwinge
2007-11-19 10:06 ` Ben Elliston

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