> On Feb 7, 2020, at 9:11 AM, chiahui chen <[email protected]> wrote:
>
> /usr/include/sqlite3ext.h:437:53: note: expanded from macro
> 'sqlite3_vsnprintf'
>
> #define sqlite3_vsnprintf sqlite3_api->vsnprintf
>
> ~~~~~~~~~~~ ^
>
> /usr/include/secure/_stdio.h:75:3: note: expanded from macro 'vsnprintf'
>
> __builtin___vsnprintf_chk (str, len, 0, __darwin_obsz(str), format, ap)
>
> ^
This appears to be your problem. The system header <secure/_stdio.h> is
defining `vsnprintf` as a macro that expands to a compiler builtin. This is
conflicting with a struct field named `vsnprintf` in the SQLite extension API.
I've never heard of <sys/_stdio.h> before, although it does exist in the macOS
SDK. Looking through the normal <stdio.h>, it does include that header at the
end:
#if defined (__GNUC__) && _FORTIFY_SOURCE > 0 && !defined (__cplusplus)
/* Security checking functions. */
#include <secure/_stdio.h>
#endif
So it looks like the trigger is that you're somehow building with
_FORTIFY_SOURCE defined, and the others are not.
Anyway, I think you could work around the problem by editing csv.c and
inserting something like this at the top:
#include <stdio.h>
#undef vsnprintf
Or else figuring out how to turn off _FORTIFY_SOURCE.
—Jens
PS: Your use of `gcc` in the command line confused me briefly — turns out `gcc`
on macOS is simply an alias for `cc`, so it invokes Clang. If you really want
GCC for some reason you'd have to install it yourself and put it in your $PATH
before /usr/bin.
_______________________________________________
sqlite-users mailing list
[email protected]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
