| Message ID | e8922627-610c-411b-af5f-4ac95d4648a6@BAMAIL02.ba.imgtec.org |
|---|---|
| State | New |
| Headers | show |
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" >
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
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.
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
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.
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
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"