From: Alexey Neyman <stilor@att.net>
To: Titus von Boxberg <titus@elbe-informatik.de>
Cc: crossgcc maillist <crossgcc@sourceware.org>
Subject: Re: AW: canadian build for mingw host: patch for gettext 0.19.8.1
Date: Fri, 21 Apr 2017 19:23:00 -0000 [thread overview]
Message-ID: <6b0b9b1a-bc1f-9c89-1168-286c9852f871@att.net> (raw)
In-Reply-To: <0cff97321de042e483ca9f7fa31fe225@SOLOWJOW.ELBE.local>
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.
next prev parent reply other threads:[~2017-04-21 19:23 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-04-21 19:16 Titus von Boxberg
2017-04-21 19:23 ` Alexey Neyman [this message]
[not found] <bb9c64d8f77542dcbdeba6e5c6a3b4d0@SOLOWJOW.ELBE.local>
2017-04-22 4:17 ` Alexey Neyman
[not found] ` <7ea27c306b3f497ab4c37205eea380a0@SOLOWJOW.ELBE.local>
2017-04-21 18:25 ` AW: " Alexey Neyman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=6b0b9b1a-bc1f-9c89-1168-286c9852f871@att.net \
--to=stilor@att.net \
--cc=crossgcc@sourceware.org \
--cc=titus@elbe-informatik.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).