Fix PRI_MACROS_BROKEN undef warnings.
diff mbox

Message ID e8922627-610c-411b-af5f-4ac95d4648a6@BAMAIL02.ba.imgtec.org
State New
Headers show

Commit Message

Steve Ellcey April 28, 2014, 9:27 p.m. UTC
Here is another undefined macro warning fix.  PRI_MACROS_BROKEN is only
used in loadmsgcat.c in the intl directory.  It is never set anywhere in
glibc sources but binutils and gcc use a intl directory that I believe is
derived from the glibc one.  The configure scripts of these products set
PRI_MACROS_BROKEN, but the intl sources in them don't appear to have been
updated from glibc since 2003.

So, if we care about keeping something that is usable with GCC/binutils
this patch seems like the best fix but if we don't care about staying in
sync with the intl directory of GCC or binutils we could just remove
PRI_MACROS_BROKEN completely or even remove the entire section of code
that sets the various PRI* macros since we know that glibc itself has the
correct definitions.

The m4 macro that binutils and GCC use to set PRI_MACROS_BROKEN mentions
AIX 4.3.3 as a platform where the macros are defined as non-string values.
There are already a number differences between intl in glibc and the one
in GCC and binutils.

Tested on mips-mti-linux-gnu with no difference in the object files
generated.

Steve Ellcey
sellcey@mips.com


2014-04-28  Steve Ellcey  <sellcey@mips.com>

	* intl/intl/loadmsgcat.c (PRI_MACROS_BROKEN): Set default value if
	not set.

Comments

Adhemerval Zanella April 28, 2014, 9:31 p.m. UTC | #1
I sent one patch to fix it sometime ago, https://sourceware.org/ml/libc-alpha/2014-03/msg00658.html;
but got no reply.  I don't which option would be preferable.


On 28-04-2014 18:27, Steve Ellcey wrote:
> Here is another undefined macro warning fix.  PRI_MACROS_BROKEN is only
> used in loadmsgcat.c in the intl directory.  It is never set anywhere in
> glibc sources but binutils and gcc use a intl directory that I believe is
> derived from the glibc one.  The configure scripts of these products set
> PRI_MACROS_BROKEN, but the intl sources in them don't appear to have been
> updated from glibc since 2003.
>
> So, if we care about keeping something that is usable with GCC/binutils
> this patch seems like the best fix but if we don't care about staying in
> sync with the intl directory of GCC or binutils we could just remove
> PRI_MACROS_BROKEN completely or even remove the entire section of code
> that sets the various PRI* macros since we know that glibc itself has the
> correct definitions.
>
> The m4 macro that binutils and GCC use to set PRI_MACROS_BROKEN mentions
> AIX 4.3.3 as a platform where the macros are defined as non-string values.
> There are already a number differences between intl in glibc and the one
> in GCC and binutils.
>
> Tested on mips-mti-linux-gnu with no difference in the object files
> generated.
>
> Steve Ellcey
> sellcey@mips.com
>
>
> 2014-04-28  Steve Ellcey  <sellcey@mips.com>
>
> 	* intl/intl/loadmsgcat.c (PRI_MACROS_BROKEN): Set default value if
> 	not set.
>
> diff --git a/intl/loadmsgcat.c b/intl/loadmsgcat.c
> index b96a997..e6483ce 100644
> --- a/intl/loadmsgcat.c
> +++ b/intl/loadmsgcat.c
> @@ -94,6 +94,11 @@ char *alloca ();
>  /* Provide fallback values for macros that ought to be defined in <inttypes.h>.
>     Note that our fallback values need not be literal strings, because we don't
>     use them with preprocessor string concatenation.  */
> +
> +#ifndef PRI_MACROS_BROKEN
> +#define PRI_MACROS_BROKEN 0
> +#endif
> +
>  #if !defined PRId8 || PRI_MACROS_BROKEN
>  # undef PRId8
>  # define PRId8 "d"
>
Roland McGrath April 28, 2014, 9:42 p.m. UTC | #2
Some of the intl/ code (including loadmsgcat.c) comes from gettext
(http://savannah.gnu.org/projects/gettext/).  Ideally we should coordinate
with those maintainers and try to keep these files exact verbatim copies,
as is the plan with things used in gnulib.  (The gettext runtime is even
licensed as LGPL>=2.1 already, so we should be able to use literally
verbatim copies without even automated munging of the copyright text.)

Let's try to do that harmonization before touching this file otherwise.
The differences in this one file look pretty small.  But really someone
should take on the task for all of intl/ to figure out which files should
be shared with gettext and review the differences.

Perhaps as part of that a change like yours will go into the gettext
version of loadmsgcat.c for libc's benefit.  Or perhaps it's appropriate
for us to just define PRI_MACROS_BROKEN to 0 in config.h.in or someplace
like that.


Thanks,
Roland
Will Newton April 29, 2014, 7:27 a.m. UTC | #3
On 28 April 2014 22:42, Roland McGrath <roland@hack.frob.com> wrote:
> Some of the intl/ code (including loadmsgcat.c) comes from gettext
> (http://savannah.gnu.org/projects/gettext/).  Ideally we should coordinate
> with those maintainers and try to keep these files exact verbatim copies,
> as is the plan with things used in gnulib.  (The gettext runtime is even
> licensed as LGPL>=2.1 already, so we should be able to use literally
> verbatim copies without even automated munging of the copyright text.)
>
> Let's try to do that harmonization before touching this file otherwise.
> The differences in this one file look pretty small.  But really someone
> should take on the task for all of intl/ to figure out which files should
> be shared with gettext and review the differences.
>
> Perhaps as part of that a change like yours will go into the gettext
> version of loadmsgcat.c for libc's benefit.  Or perhaps it's appropriate
> for us to just define PRI_MACROS_BROKEN to 0 in config.h.in or someplace
> like that.

I created this page on the wiki in an attempt to understand which
files come from where:

https://sourceware.org/glibc/wiki/SharedSourceFiles

I haven't had chance to do any detailed analysis yet but hopefully it's a start.
Siddhesh Poyarekar April 29, 2014, 7:48 a.m. UTC | #4
On Tue, Apr 29, 2014 at 08:27:55AM +0100, Will Newton wrote:
> I created this page on the wiki in an attempt to understand which
> files come from where:
> 
> https://sourceware.org/glibc/wiki/SharedSourceFiles
> 
> I haven't had chance to do any detailed analysis yet but hopefully it's a start.

I think we have agreed in the past the malloc and resolv sources have
diverged sufficiently from the original sources to make merging a very
difficult exercise.  Following that, Ondrej also made some formatting
changes in the malloc code so that it reads similar to the rest of
glibc sources.

So those two blocks could be dropped from the shared source files
list, unless you want to keep them there for reference.

Siddhesh
Carlos O'Donell April 29, 2014, 9:05 a.m. UTC | #5
On 04/29/2014 03:48 AM, Siddhesh Poyarekar wrote:
> On Tue, Apr 29, 2014 at 08:27:55AM +0100, Will Newton wrote:
>> I created this page on the wiki in an attempt to understand which
>> files come from where:
>>
>> https://sourceware.org/glibc/wiki/SharedSourceFiles
>>
>> I haven't had chance to do any detailed analysis yet but hopefully it's a start.
> 
> I think we have agreed in the past the malloc and resolv sources have
> diverged sufficiently from the original sources to make merging a very
> difficult exercise.  Following that, Ondrej also made some formatting
> changes in the malloc code so that it reads similar to the rest of
> glibc sources.
> 
> So those two blocks could be dropped from the shared source files
> list, unless you want to keep them there for reference.

I suggest they stay as reference, but that's all.

We are going to own malloc and resolv going forward.

Either we replace them wholesale later or keep using our heavily
modified versions.

Cheers,
Carlos.
Steve Ellcey April 30, 2014, 4:22 p.m. UTC | #6
On Mon, 2014-04-28 at 14:42 -0700, Roland McGrath wrote:

> Let's try to do that harmonization before touching this file otherwise.
> The differences in this one file look pretty small.  But really someone
> should take on the task for all of intl/ to figure out which files should
> be shared with gettext and review the differences.
> 
> Perhaps as part of that a change like yours will go into the gettext
> version of loadmsgcat.c for libc's benefit.  Or perhaps it's appropriate
> for us to just define PRI_MACROS_BROKEN to 0 in config.h.in or someplace
> like that.
> 
> 
> Thanks,
> Roland

I looked at using configure to define PRI_MACROS_BROKEN but the intl
directory in glibc doesn't have a configure file and creating one just
for PRI_MACROS_BROKEN seemed a bit excessive.  I sent email to the
gettext list and they checked in a change to define
PRI_MACROS_BROKEN to 0 if it is not already defined when compiled.

I know that is not our preferred solution for glibc specific code but
hopefully it is OK in shared code.

So if we pick up the latest gettext sources and move it into glibc we
should get this fix as a side affect of that import.  I am not going to
look at doing that right now, but might be able to look into it at some
point if no one else gets to it first.

http://lists.gnu.org/archive/html/bug-gettext/2014-04/msg00027.html

Steve Ellcey
sellcey@mips.com

Patch
diff mbox

diff --git a/intl/loadmsgcat.c b/intl/loadmsgcat.c
index b96a997..e6483ce 100644
--- a/intl/loadmsgcat.c
+++ b/intl/loadmsgcat.c
@@ -94,6 +94,11 @@  char *alloca ();
 /* Provide fallback values for macros that ought to be defined in <inttypes.h>.
    Note that our fallback values need not be literal strings, because we don't
    use them with preprocessor string concatenation.  */
+
+#ifndef PRI_MACROS_BROKEN
+#define PRI_MACROS_BROKEN 0
+#endif
+
 #if !defined PRId8 || PRI_MACROS_BROKEN
 # undef PRId8
 # define PRId8 "d"