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

[Alexey Neyman <stilor at att dot 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.