| Issue |
76050
|
| Summary |
LLDB build for MinGW broken by unexpected include of unistd.h
|
| Labels |
lldb,
platform:windows
|
| Assignees |
|
| Reporter |
mstorsjo
|
Builds of LLDB for MinGW targets, with libc++ as the C++ standard library, was recently broken by an entirely unrelated change in libc++, commit 2fd4084fca0c474c2232533263182945bd1ebe17. An example of such a failed build: https://github.com/mstorsjo/llvm-mingw/actions/runs/7269329294/job/19809313900
To lay out the situation; mingw-w64's `getopt.h` header, https://github.com/mingw-w64/mingw-w64/blob/v11.0.1/mingw-w64-headers/crt/getopt.h, does define `optreset` only if `_BSD_SOURCE` was defined.
LLDB's use of `getopt.h` does require using `optreset`. To make sure this is available, LLDB does define `_BSD_SOURCE` right before including `getopt.h`: https://github.com/llvm/llvm-project/blob/main/lldb/include/lldb/Host/HostGetOpt.h#L12-L18
Mingw-w64's `unistd.h` also includes `getopt.h`, as one can expect to have `getopt` available after including `unistd.h`: https://github.com/mingw-w64/mingw-w64/blob/v11.0.1/mingw-w64-headers/crt/unistd.h#L12
Now at this point, the innocent libc++ change in 2fd4084fca0c474c2232533263182945bd1ebe17 caused more of libc++'s headers to include `<unistd.h>`, e.g. here: https://github.com/llvm/llvm-project/blob/2fd4084fca0c474c2232533263182945bd1ebe17/libcxx/include/print#L52-L54 (that line was preexisting, but the change made more headers include `<print>`).
Thus, LLDB includes a bunch of C++ standard headers, which end up bringing in `unistd.h`, which includes `getopt.h`. This then renders a later `#define _BSD_SOURCE` `#include <getopt.h>` in `HostGetOpt.h` without effect.
I guess this generally is a brittle pattern - defines such as `_BSD_SOURCE` or `_GNU_SOURCE` generally need to be defined on the command line, to be sure they applies as headers can be included transitively, earlier than expected.
Alternatively, the mingw-w64 `getopt.h` header could be adapted to react to being reincluded with `_BSD_SOURCE` defined, after first being included once without it.
CC @DavidSpickett
![]()
_______________________________________________
llvm-bugs mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
