I see. I had better check whether build with (-D_XOPEN_SOURCE=700)
satisfies my requirements first before using extensions.
Thank you for your prompt reply. :)

2019년 7월 31일 (수) 오전 12:51, Rich Felker <dalias@libc.org>님이 작성:

> On Wed, Jul 31, 2019 at 12:31:17AM +0900, Jeeyong Um wrote:
> > Hello.
> > I have a question about building musl with `_BSD_SOURCE` definition.
> >
> > `src/time/__tz.c` has static variable named by `index` (line 25) and
> > include `string.h` header file (line 5).
> > 5  #include <string.h>
> > 25 static const unsigned char *zi, *trans, *index, *types, *abbrevs,
> > *abbrevs_end;
> >
> > By the way, `include/string.h` includes `strings.h` when _BSD_SOURCE is
> > defined (line 57).
> > 56 #if defined(_BSD_SOURCE) || defined(_GNU_SOURCE)
> > 57 #include <strings.h>
> > 58 #endif
> >
> > `include/strings.h` has a function named by `index` too (line 19).
> > 13 #if defined(_GNU_SOURCE) || defined(_BSD_SOURCE) ||
> > defined(_POSIX_SOURCE) \
> > 14  || (defined(_POSIX_C_SOURCE) && _POSIX_C_SOURCE+0 < 200809L) \
> > 15  || (defined(_XOPEN_SOURCE) && _XOPEN_SOURCE+0 < 700)
> > 16 int bcmp (const void *, const void *, size_t);
> > 17 void bcopy (const void *, void *, size_t);
> > 18 void bzero (void *, size_t);
> > 19 char *index (const char *, int);
> > 20 char *rindex (const char *, int);
> > 21 #endif
> >
> > Is it possible to build musl with _BSD_SOURCE definition in this case?
> > Even though `static` modifier limits the scope of variable to the file,
> the
> > conflict between `index` of `strings.h` and `index` of `__tz.c` seems
> > unavoidable.
> > Please let me know if you find any mistakes here.
>
> The musl source files assume the default feature test macros provided
> by their makefile, -D_XOPEN_SOURCE=700 which also includes POSIX base,
> no extensions. Extensions by their nature bring into the namespace
> things that might conflict with valid code.
>
> If -D_BSD_SOURCE is getting into the build for musl, it likely means
> you have a larger build system problem, like injecting it into CFLAGS
> for every package you build. This might be making some "spurious"
> problems go away, but it very well could create others. It would be
> much better to fix whatever prompted you to do this to begin with. If
> that's not practical, at least remove it from your build for musl.
>
> Rich
>