X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f X-Recipient: geda-user AT delorie DOT com Message-ID: <567D7AD9.8080002@tio.cz> Date: Fri, 25 Dec 2015 18:20:25 +0100 From: Jan Damborsky User-Agent: Mozilla/5.0 (X11; SunOS i86pc; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: geda-user AT delorie DOT com Subject: Re: [geda-user] Building pcb on Solaris References: <567D1175 DOT 3030705 AT tio DOT cz> <20151225102357 DOT 16247 DOT qmail AT stuge DOT se> In-Reply-To: <20151225102357.16247.qmail@stuge.se> Content-Type: multipart/alternative; boundary="------------080206020900020706060207" Reply-To: geda-user AT delorie DOT com This is a multi-part message in MIME format. --------------080206020900020706060207 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Hi Peter, to follow up on my previous email, I have taken a closer look at how those files interact with locale.h -there seem to be two scenarios. [1] main.c, print.c Those two files call setlocale() API if ENABLE_NFS is defined. So it seems to me that those two files should include locale.h in that case, since this is how setlocale() API is made available to the consumers. [2] gui-config.c, gui-misc.c, gui-netlist-window.c, report.c Those files do not seem to consume any locale.h API directly, but they all call C_() macro which is defined in global.h: # define C_(C, S) pgettext(C, S) pgettext() macro is in turn defined in gettext.h as #ifdef DEFAULT_TEXT_DOMAIN # define pgettext(Msgctxt, Msgid) \ pgettext_aux (DEFAULT_TEXT_DOMAIN, Msgctxt GETTEXT_CONTEXT_GLUE Msgid, Msgid, LC_MESSAGES) #else # define pgettext(Msgctxt, Msgid) \ pgettext_aux (NULL, Msgctxt GETTEXT_CONTEXT_GLUE Msgid, Msgid, LC_MESSAGES) #endif pgettext_aux () takes LC_MESSAGES as an argument. Since LC_MESSAGES is provided by locale.h, gettext.h should include it. Based on that, it seems that following three files should include locale.h: src/main.c src/print.c src/gettext.h There is already a check for locale.h in configure.ac, so I took advantage of that. I have updated bug report with this evaluation and attached patch with proposed fix. I have tested these changes on Oracle Solaris 11.3 and Ubunutu 14.04. In both cases, tried to build with both NLS support enabled and disabled. Best regards, Jan On 12/25/15 11:23 AM, Peter Stuge (peter AT stuge DOT se) [via geda-user AT delorie DOT com] wrote: > Hi Jan, > > Jan Damborsky wrote: >> Deploying those tools on Solaris is straightforward, I justneed to deal >> with a small issue when building pcb - compilation fails due to following >> files missing header: >> >> $ git status -s >> M src/hid/gtk/gui-config.c >> M src/hid/gtk/gui-misc.c >> M src/hid/gtk/gui-netlist-window.c >> M src/main.c >> M src/print.c >> M src/report.c >> >> Adding to those filessolves the problem. >> Tried that on Linux as well (Ubuntu 14.04), but Linux doesn't complain >> which is perhaps the reason why that issue has not been reported so far. >> I am wondering if it would make sense to file bug for this and fix that. > I think so, we still need to find the right way to fix it. > >> If desired, I am willing to do whatever is needed to integrate >> those changes into the upstream, just would need some guidance >> to go through the processes. > Filing a bug is a good first step. Next steps would be: > > * find out why locale.h is required > * find out whether that is correct > + if no, find what to do instead and implement that > + if yes, check for locale.h in configure.ac and add #include within > #if HAVE_LOCALE_H in the source files where locale.h is required > * commit locally > * either: git format-patch -1, then attach patch to the bug > or: git push to somewhere and ask here for review+possible merge > > > //Peter --------------080206020900020706060207 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Hi Peter,

to follow up on my previous email, I have taken a closer look
at how those files interact with locale.h - the= re seem to be two scenarios.

[1] main.c, print.c

Those two files call setlocale() API if ENABLE_NFS is defined.
So it seems to me that those two files should include locale.h
in that case, since this is how setlocale() API is made available
to the consumers.

[2] gui-config.c, gui-misc.c, gui-netlist-wi= ndow.c, report.c

Those files do not seem to consume any locale.h API directly,
but they all call C_() macro which is defined in global.h:

# define C_(C, S) pgettext(C, S)

pgettext() macro is in turn defined in gettext.h as

#ifdef DEFAULT_TEXT_DOMAIN
 # define pgettext(Msgctxt, Msgid) \
 =A0=A0=A0pgettext_aux (DEFAULT_TEXT_DOMAIN, Msg= ctxt GETTEXT_CONTEXT_GLUE Msgid, Msgid, LC_MESSAGES)
 #else
 # define pgettext(Msgctxt, Msgid) \
 =A0=A0=A0pgettext_aux (NULL, Msgctxt GETTEXT_CO= NTEXT_GLUE Msgid, Msgid, LC_MESSAGES)
 #endif

pgettext_aux () takes LC_MESSAGES as an argument.
Since LC_MESSAGES is provided by locale.h, gettext.h should include it.

Based on that, it seems that following three files should include locale.h:

src/main.c
 src/print.c
 src/gettext.h

There is already a check for locale.h in configure.ac,
so I took advantage of that.

I have updated bug report with this evaluation and attached
patch with proposed fix. I have tested these changes on Oracle Solaris 11.3
and Ubunutu 14.04. In both cases, tried to build with both NLS support
enabled and disabled.

Best regards,
Jan

On 12/25/15 11:23 AM, Peter Stuge (peter AT stuge DOT se) [via geda-user AT delorie DOT com] wrote:
Hi Jan,

Jan Damborsky wrote:

Deploying those tools on Solaris is straightforwar=
d, I justneed to deal
with a small issue when building pcb - compilation fails due to following
files missing <locale.h> header:

$ git status -s
M src/hid/gtk/gui-config.c
M src/hid/gtk/gui-misc.c
M src/hid/gtk/gui-netlist-window.c
M src/main.c
M src/print.c
M src/report.c

Adding <locale.h> to those filessolves the problem.
Tried that on Linux as well (Ubuntu 14.04), but Linux doesn't complain
which is perhaps the reason why that issue has not been reported so far.
I am wondering if it would make sense to file bug for this and fix that.

I think so, we still need to find the right way to fix it.


If desired, I am willing to do whatever is needed =
to integrate
those changes into the upstream, just would need some guidance
to go through the processes.

Filing a bug is a good first step. Next steps would be:

* find out why locale.h is required
* find out whether that is correct
+ if no, find what to do instead and implement that
+ if yes, check for locale.h in configure.ac and add #include within
  #if HAVE_LOCALE_H in the source files where locale.h is required
* commit locally
* either: git format-patch -1, then attach patch to the bug
  or: git push to somewhere and ask here for review+possible merge


//Peter

--------------080206020900020706060207--