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

[Alexey Neyman <stilor@att.net>]

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.