emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Android port


From: Po Lu
Subject: Re: Android port
Date: Sat, 05 Aug 2023 20:16:32 +0800
User-agent: Gnus/5.13 (Gnus v5.13)

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Bruno Haible <bruno@clisp.org>
>> Cc: Po Lu <luangruo@yahoo.com>, Paul Eggert <eggert@cs.ucla.edu>, Eli 
>> Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org
>> Date: Sat, 05 Aug 2023 13:20:31 +0200
>> 
>> But from this error log:
>> 
>> In file included from 
>> C:/msys64/tmp/emacs-bfbdf4eb892935536fc665d6cc986fd669364263/nt/inc/ms-w32.h:389,
>>                  from ../src/conf_post.h:38,
>>                  from ../src/config.h:3511,
>>                  from printf.c:18:
>> C:/msys64/mingw64/include/stdio.h:379:5: note: previous definition of 
>> 'printf' with type 'int(const char *, ...)'
>> 
>> it seems that nt/inc/ms-w32.h directly includes <stdio.h> from mingw, without
>> the interposed lib/stdio.h.
>> 
>> Do you have a lib/stdio.h in your build tree?
>
> The MinGW build omits building the Gnulib's stdio module.  We did that
> since 2017.  The exact reasons are probably lost in time, but I can
> assure you they were real, and I wouldn't want to reintroduce them for
> this particular reason.
>
> Since the *printf family doesn't need to be replaced in the Emacs
> build on MS-Windows, I'd rather we understood why the above causes
> compilation errors.  Aren't Gnulib replacements for *printf functions
> supposed to have prototypes compatible to the MinGW headers?

Judging from the headers Angelo provided, the issue lies in MinGW's
headers defining (not merely declaring) asprintf:

#ifdef _GNU_SOURCE
__mingw_ovr
__attribute__ ((__format__ (gnu_printf, 2, 3))) __attribute__((nonnull (1,2)))
int asprintf(char **__ret, const char *__format, ...)
{
  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;
}

IMHO, the least risky solution remains disabling the vasprintf module
entirely.  We can revisit this problem when and if Emacs begins to rely
on ISO C2X and C99 features supplied by Gnulib.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]