wxWidgets conflict with boost::process

[Blakjak88]

Describe the bug I have wxWidgets 3.1.5#2 installed with x64-windows-static triplet and boost-process 1.76.0 with the same triplet.

The header setup.h in wxWidgets defines pid_t as an int.

In boost-process file child-handle.hpp this is typedef to a DWORD_. This causes a compile error when using both wxWidgets and boost-process in the same application.

Workaround is to #undef pid_t where boost headers are imported.

This appears to only impact when using VCPKG. The setup.h file in the source code of wxWidgets does not #define pid_t to int. Is this an old setup.h file in VCPKG?

Environment

• OS: Windows.
• Compiler: Visual Studio 2022 Preview. v143.

To Reproduce Steps to reproduce the behavior:

1. Compile an application using both wxWidgets and boost-process installed with VCPKG.

Expected behavior This conflict should not occur as this pid_t type should not be defined in wxWidgets setup.h

Failure logs

Additional context

[NancyLi1013]

Hi @Blakjak88

Thanks for posting this issue.

This seems like upstream bug.

According to this issue https://trac.wxwidgets.org/ticket/18150, pid_t should only be used on Unix. But we can found the related codes here:

pid_t is added to ${SYSTYPES}, but there is no check if <sys/types.h> is defined in build/cmake/setup.cmake

# Check size and availability of various types
set(SYSTYPES
    pid_t size_t
    wchar_t int long short
    gid_t uid_t
    )

https://github.com/wxWidgets/wxWidgets/blob/95f1b262a4da7b5b246ca8d64c36972f5d109c3a/build/cmake/setup.cmake#L651

And there is also no any additional condition for this:

configure_file(build/cmake/setup.h.in ${wxSETUP_HEADER_FILE})

@vadz, Could you please help take a look if this is a bug for wxwidgets?

Thanks.

[vadz]

I guess we could move pid_t to the non-MSVC-case, i.e. append it with mode_t and off_t as it's indeed only needed under Unix.

But in fact I think we probably could avoid checking for it and defining it completely nowadays, I don't think there are any Unix systems not defining this type left, so we could simply drop all checks for it as I've just done in the PR mentioned above. If this doesn't result in any problems, it will be included in wx 3.1.6.

[NancyLi1013]

Thanks for looking into this problem and also for your help. @vadz Sounds great!

[JackBoosY]

I completely lost track with this issue, since wxwidgets was updated for several versions, is this issue still exist?

[JackBoosY]

Please reopen or ping me to reopen this issue if it still bother you.

Thanks.