Re: cross-compiling packages

[Roland Illig <roland.illig%gmx.de@localhost>]

On 06.11.2020 05:03, Brook Milligan wrote:
> > On Nov 5, 2020, at 1:00 AM, Roland Illig <roland.illig%gmx.de@localhost> wrote:
> > On 05.11.2020 05:22, Brook Milligan wrote:
> > > snprintf.c:43:1: error: expected declaration specifiers or '...' before numeric constant
> > >     43 | snprintf(char *str, size_t size, const char *format, ...)
> > >        | ^~~~~~~~
> >
> > This looks like a C preprocessor issue to me.
>
> int __builtin___snprintf_chk(char *str, size_t size, 0, __builtin_object_size(char *str, 2 > 1), const char *format, ...)
>
> Does this make sense?  Why the values instead of types?  I have never looked at the magic created by the preprocessor, so please advise.

The C standard allows every function to be implemented as a plain
function or as a preprocessor macro or both.  In this case, there is a
preprocessor macro named snprintf.

From the name __builtin_object_size I guess that the macro comes from
GCC itself, but it may also be from the system headers.

When the function snprintf is called, this macro expansion is useful,
and that's what it is made for.

Almost nobody defines the snprintf function though.  Those who do must
work around the macro.

The usual way to deal with macros like these is to simply undefine the
corresponding macro, above the line that defines the function.  In your
case:

#undef snprintf
int
snprintf(char *str, size_t size, const char *format, ...)

I wonder though why you are the first or only one to experience this.
Either your setup is really unique, which would be ok, or your setup is
simply wrong.

In a cross-compile build, it looks suspicious to have -I/usr/include, at
least when building something for the target platform.  This directory
must only be used for code intended for the host platform.

Roland