Re: AW: canadian build for mingw host: patch for gettext 0.19.8.1

Re: AW: canadian build for mingw host: patch for gettext 0.19.8.1

[Alexey Neyman]

On 04/21/2017 10:59 AM, Titus von Boxberg wrote:
> Alexey, all,
>
> see below:
>
>> -----Ursprüngliche Nachricht-----
>> Von: Alexey Neyman [mailto:stilor@att.net]
>> Gesendet: Freitag, 21. April 2017 18:17
>> An: Titus von Boxberg <titus@elbe-informatik.de>
>> Cc: crossgcc maillist <crossgcc@sourceware.org>
>> Betreff: Re: canadian build for mingw host: patch for gettext 0.19.8.1
>>
>> [CC crossgcc list]
>>
>> Hi Titus,
>>
>> First off, please send the emails the crossgcc mailing list, not to me
>> personally - I may not be the only person interested in a certain patch,
>> etc.
>>
>>
>> On 04/21/2017 04:12 AM, Titus von Boxberg wrote:
>>> Hi Alexey,
>>>
>>> I had to use the patch below to let ct-ng build gettext 0.19.8.1 for host
>> mingw.
>>> I don't use mingw nor gettext at all (besides for running a cross gcc
>>> on windows), so I don't really understand why it's required (or rather why
>> mingw defines asprintf).
>> asprintf is more or less common function now.
>>
>> Can you describe how you set up the mingw host? I'd like to add it to our
>> docs and add that to our testing regimen.
> I use a (rather old) i686-w64-mingw32 cross compiler from Linux to mingw.
> gcc version 4.7.2
What do you use as a shell, etc? Cygwin?

>> As to the patch itself, what was the problem with using asprintf from
>> mingw's libraries? A build log fragment would be helpful.
> gettext contains three definitions of asprintf in three files asprintf.c
> These conflict with a static implementation of asprintf in mingw header stdio.h
> As I said: Unfortunately, I don't have a clue about gettext and mingw.
I looked at mingw's <stdio.h> and I see what the problem is. The 
function is actually not static - had it been, e.g., 'static inline', it 
wouldn't have conflicted with a built-in implementation of asprintf().

So, the patch makes sense, but I am not sure if it should be fixed by 
mingw instead.
>
>>> I took the idea for the patch from
>>> https://lists.freedesktop.org/archives/gstreamer-commits/2015-November
>>> /090748.html
>>>
>>> Second, it looks strange to me that gettext is built at all for the host.
>>> gettext is _NEEDED by glibc.
>> It is needed to enable localization in the toolchain components. I haven't
>> tested that area much myself, though.
> Yes, but I disabled NLS.
>
>> And, I think you got it exactly the other way. gettext is not *needed* by
>> glibc, it is *a part of glibc*. We only build it for *non-glibc*
>> hosts/targets.
> By "_NEEDED" I meant the ct-ng variable GETTEXT_NEEDED
I see.

The commit message states:

commit 9e81836b8124efd11805e8050034492a8831208b
Author: Ray Donnelly <mingw.android@gmail.com>
Date:   Sat Oct 24 01:49:56 2015 +0100

     Add gettext and libiconv as companion libs

     .. they're needed for the RPC generation in glibc
     on both Cygwin and MinGW-w64.

So apparently, the cross_rpcgen (on *build*, rather than *host*) needs 
it. In case of a simple cross, of course, build==host.

> This is set when choosing NLS, and when choosing glibc for target,
> at least according to config/libc/glibc.
> Anyway, I have
> # CT_TOOLCHAIN_ENABLE_NLS is not set
> and
> CT_GETTEXT_NEEDED=y
> in my .config
>
>>> For the target: OK, may it be so. But why for the host? glibc
>>> shouldn't have anything to do with the host? Is that correct?
>> Hint: not all our supported hosts are glibc-based. If you look at the build
>> script, you'll notice that gettext is skipped if the host is *-linux-gnu*.
> Again, I'm afraid I don't get it.
> I'd assume that when I disable NLS gettext is not needed for the host.
Apparently, not just NLS - see above.

Regards,
Alexey.

Re: canadian build for mingw host: patch for gettext 0.19.8.1

[Alexey Neyman]

[CC crossgcc list]

Hi Titus,

First off, please send the emails the crossgcc mailing list, not to me 
personally - I may not be the only person interested in a certain patch, 
etc.


On 04/21/2017 04:12 AM, Titus von Boxberg wrote:
> Hi Alexey,
>
> I had to use the patch below to let ct-ng build gettext 0.19.8.1 for host mingw.
>
> I don't use mingw nor gettext at all (besides for running a cross gcc on windows),
> so I don't really understand why it's required (or rather why mingw defines asprintf).
asprintf is more or less common function now.

Can you describe how you set up the mingw host? I'd like to add it to 
our docs and add that to our testing regimen.

As to the patch itself, what was the problem with using asprintf from 
mingw's libraries? A build log fragment would be helpful.
> I took the idea for the patch from
> https://lists.freedesktop.org/archives/gstreamer-commits/2015-November/090748.html
>
> Second, it looks strange to me that gettext is built at all for the host.
> gettext is _NEEDED by glibc.
It is needed to enable localization in the toolchain components. I 
haven't tested that area much myself, though.

And, I think you got it exactly the other way. gettext is not *needed* 
by glibc, it is *a part of glibc*. We only build it for *non-glibc* 
hosts/targets.
> For the target: OK, may it be so. But why for the host? glibc shouldn't have
> anything to do with the host? Is that correct?
Hint: not all our supported hosts are glibc-based. If you look at the 
build script, you'll notice that gettext is skipped if the host is 
*-linux-gnu*.

Regards,
Alexey.

Re: AW: canadian build for mingw host: patch for gettext 0.19.8.1

[Alexey Neyman]

On 04/21/2017 12:15 PM, Titus von Boxberg wrote:
>
>> -----Ursprüngliche Nachricht-----
>> Von: Alexey Neyman [mailto:stilor@att.net]
>> Gesendet: Freitag, 21. April 2017 20:26
>> An: Titus von Boxberg <titus@elbe-informatik.de>
>> Cc: crossgcc maillist <crossgcc@sourceware.org>
>> Betreff: Re: AW: canadian build for mingw host: patch for gettext 0.19.8.1
>>
>> On 04/21/2017 10:59 AM, Titus von Boxberg wrote:
>>> Alexey, all,
>>>
>>> see below:
>>>
>>>> -----Ursprüngliche Nachricht-----
>>>> Von: Alexey Neyman [mailto:stilor@att.net]
>>>> Gesendet: Freitag, 21. April 2017 18:17
>>>> An: Titus von Boxberg <titus@elbe-informatik.de>
>>>> Cc: crossgcc maillist <crossgcc@sourceware.org>
>>>> Betreff: Re: canadian build for mingw host: patch for gettext
>>>> 0.19.8.1
>>>>
>>>> [CC crossgcc list]
>>>>
>>>> Hi Titus,
>>>>
>>>> First off, please send the emails the crossgcc mailing list, not to
>>>> me personally - I may not be the only person interested in a certain
>>>> patch, etc.
>>>>
>>>>
>>>> On 04/21/2017 04:12 AM, Titus von Boxberg wrote:
>>>>> Hi Alexey,
>>>>>
>>>>> I had to use the patch below to let ct-ng build gettext 0.19.8.1 for
>>>>> host
>>>> mingw.
>>>>> I don't use mingw nor gettext at all (besides for running a cross
>>>>> gcc on windows), so I don't really understand why it's required (or
>>>>> rather why
>>>> mingw defines asprintf).
>>>> asprintf is more or less common function now.
>>>>
>>>> Can you describe how you set up the mingw host? I'd like to add it to
>>>> our docs and add that to our testing regimen.
>>> I use a (rather old) i686-w64-mingw32 cross compiler from Linux to mingw.
>>> gcc version 4.7.2
>> What do you use as a shell, etc? Cygwin?
> I'm afraid I don't get the question.
> On the ct-ng build machine (Linux), I installed
> i686-w64-mingw32-gcc-4.7.2-release-linux64_rubenvb.tar.xz
> That's it, afair.
> The shell on the host (Windows) is beyond the canadian build (on Linux).
> Anyway, I don't use cygwin at all.
Ah, I missed 'canadian' in the Subject line. Sorry.
>>>> As to the patch itself, what was the problem with using asprintf from
>>>> mingw's libraries? A build log fragment would be helpful.
>>> gettext contains three definitions of asprintf in three files
>>> asprintf.c These conflict with a static implementation of asprintf in
>>> mingw header stdio.h As I said: Unfortunately, I don't have a clue about
>> gettext and mingw.
>> I looked at mingw's <stdio.h> and I see what the problem is. The function is
>> actually not static - had it been, e.g., 'static inline', it wouldn't have
>> conflicted with a built-in implementation of asprintf().
>>
>> So, the patch makes sense, but I am not sure if it should be fixed by mingw
>> instead.
> No, the asprintf in (my) mingw's stdio.h is static:
>
> static __attribute__ ((__unused__))
> __attribute__ ((__format__ (gnu_printf, 2, 3))) __attribute__((nonnull (1,2)))
> int asprintf(char **__ret, const char *__format, ...)
> {
>    register int __retval;
>    __builtin_va_list __local_argv; __builtin_va_start( __local_argv, __format );
>    __retval = __mingw_vasprintf( __ret, __format, __local_argv );
>    __builtin_va_end( __local_argv );
>    return __retval;
> }
>
>
> With my nonexistent knowledge of gettext, I'd deduce that the problem
> could be either that gettext's configure does not check for
> an external implementation of asprintf at all, or that it cannot detect this
> implementation. In either way, it apparently chooses to bring in
> gettext's own implementation of asprintf which leads to the duplicate
> definition when compiling gettext's asprintf.c

In the current version of i686-w64-mingw32 sample's <stdio.h> it looks 
like this:

__mingw_ovr
__attribute__ ((__format__ (gnu_printf, 2, 3))) __attribute__((nonnull 
(1,2)))
int asprintf(char **__ret, const char *__format, ...)
{
   register int __retval;
   __builtin_va_list __local_argv; __builtin_va_start( __local_argv, 
__format );
   __retval = __mingw_vasprintf( __ret, __format, __local_argv );
   __builtin_va_end( __local_argv );
   return __retval;
}

So, it apparently breaks with either static or not.

Please file an issue on Github so that I do not forget about this issue. 
Attach your .config and the patch.

Thanks,
Alexey.

AW: canadian build for mingw host: patch for gettext 0.19.8.1

[Titus von Boxberg]

> -----Ursprüngliche Nachricht-----
> Von: Alexey Neyman [mailto:stilor@att.net]
> Gesendet: Freitag, 21. April 2017 20:26
> An: Titus von Boxberg <titus@elbe-informatik.de>
> Cc: crossgcc maillist <crossgcc@sourceware.org>
> Betreff: Re: AW: canadian build for mingw host: patch for gettext 0.19.8.1
> 
> On 04/21/2017 10:59 AM, Titus von Boxberg wrote:
> > Alexey, all,
> >
> > see below:
> >
> >> -----Ursprüngliche Nachricht-----
> >> Von: Alexey Neyman [mailto:stilor@att.net]
> >> Gesendet: Freitag, 21. April 2017 18:17
> >> An: Titus von Boxberg <titus@elbe-informatik.de>
> >> Cc: crossgcc maillist <crossgcc@sourceware.org>
> >> Betreff: Re: canadian build for mingw host: patch for gettext
> >> 0.19.8.1
> >>
> >> [CC crossgcc list]
> >>
> >> Hi Titus,
> >>
> >> First off, please send the emails the crossgcc mailing list, not to
> >> me personally - I may not be the only person interested in a certain
> >> patch, etc.
> >>
> >>
> >> On 04/21/2017 04:12 AM, Titus von Boxberg wrote:
> >>> Hi Alexey,
> >>>
> >>> I had to use the patch below to let ct-ng build gettext 0.19.8.1 for
> >>> host
> >> mingw.
> >>> I don't use mingw nor gettext at all (besides for running a cross
> >>> gcc on windows), so I don't really understand why it's required (or
> >>> rather why
> >> mingw defines asprintf).
> >> asprintf is more or less common function now.
> >>
> >> Can you describe how you set up the mingw host? I'd like to add it to
> >> our docs and add that to our testing regimen.
> > I use a (rather old) i686-w64-mingw32 cross compiler from Linux to mingw.
> > gcc version 4.7.2
> What do you use as a shell, etc? Cygwin?

I'm afraid I don't get the question.
On the ct-ng build machine (Linux), I installed
i686-w64-mingw32-gcc-4.7.2-release-linux64_rubenvb.tar.xz
That's it, afair.
The shell on the host (Windows) is beyond the canadian build (on Linux).
Anyway, I don't use cygwin at all.

> 
> >> As to the patch itself, what was the problem with using asprintf from
> >> mingw's libraries? A build log fragment would be helpful.
> > gettext contains three definitions of asprintf in three files
> > asprintf.c These conflict with a static implementation of asprintf in
> > mingw header stdio.h As I said: Unfortunately, I don't have a clue about
> gettext and mingw.
> I looked at mingw's <stdio.h> and I see what the problem is. The function is
> actually not static - had it been, e.g., 'static inline', it wouldn't have
> conflicted with a built-in implementation of asprintf().
> 
> So, the patch makes sense, but I am not sure if it should be fixed by mingw
> instead.

No, the asprintf in (my) mingw's stdio.h is static:

static __attribute__ ((__unused__))
__attribute__ ((__format__ (gnu_printf, 2, 3))) __attribute__((nonnull (1,2)))
int asprintf(char **__ret, const char *__format, ...)
{
  register int __retval;
  __builtin_va_list __local_argv; __builtin_va_start( __local_argv, __format );
  __retval = __mingw_vasprintf( __ret, __format, __local_argv );
  __builtin_va_end( __local_argv );
  return __retval;
}


With my nonexistent knowledge of gettext, I'd deduce that the problem
could be either that gettext's configure does not check for
an external implementation of asprintf at all, or that it cannot detect this
implementation. In either way, it apparently chooses to bring in
gettext's own implementation of asprintf which leads to the duplicate
definition when compiling gettext's asprintf.c

Regards,
Titus