Issue when compiling with MinGW and pthreads

--===============1269515740014205303==
Content-Type: multipart/alternative; boundary="f403045c86964e3bb20561e0d87b"

--f403045c86964e3bb20561e0d87b
Content-Type: text/plain; charset="UTF-8"

Dear OpenEXR developpers,

I have an old issue when building IlmBase with MinGW, which is still there
in 2.2.1

MinGW comes in two thread API flavors : the win32 or pthreads API. The most
widely used is the pthread flavor, as shown on the sourceforge download
page:

https://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/mingw-builds/7.2.0/

However, the thread part of IlmBase uses that preprocessor code:

#if defined _WIN32 || defined _WIN64
    #ifdef NOMINMAX
        #undef NOMINMAX
    #endif
    #define NOMINMAX
    #include <windows.h>
    #include <process.h>
#elif HAVE_PTHREAD
    #include <pthread.h>
#endif

With MinGW pthread flavor, _WIN32 is always defined, and autoconf properly
sets the HAVE_PTHREAD macro. Which means both are defined. The above
preprocessor code then includes the Win32 API which is incorrect, causing
compile errors. Replacing the whole preprocessor block by:

    #include <pthread.h>

In all threading ilmbase source solves the issue.

Would it be possible to patch this? I think that first testing for
HAVE_PTHREADS and testing for _WIN32 if the first is not set would solve
the issue, without harm to other platforms and compilers. What do you think?

Thanks!

--f403045c86964e3bb20561e0d87b
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><div><div><div><div><div><div>Dear OpenEXR developper=
s,<br><br></div>I have an old issue when building IlmBase with MinGW, which=
 is still there in 2.2.1<br><br></div>MinGW comes in two thread API flavors=
 : the win32 or pthreads API. The most widely used is the pthread flavor, a=
s shown on the sourceforge download page:<br><br><a href=3D"https://sourcef=
orge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%=
20Builds/mingw-builds/7.2.0/">https://sourceforge.net/projects/mingw-w64/fi=
les/Toolchains%20targetting%20Win32/Personal%20Builds/mingw-builds/7.2.0/</=
a><br><br></div>However, the thread part of IlmBase uses that preprocessor =
code:<br><br>#if defined _WIN32 || defined _WIN64<br>=C2=A0=C2=A0=C2=A0 #if=
def NOMINMAX<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 #undef NOMINMAX<=
br>=C2=A0=C2=A0=C2=A0 #endif<br>=C2=A0=C2=A0=C2=A0 #define NOMINMAX<br>=C2=
=A0=C2=A0=C2=A0 #include &lt;windows.h&gt;<br>=C2=A0=C2=A0=C2=A0 #include &=
lt;process.h&gt;<br>#elif HAVE_PTHREAD<br>=C2=A0=C2=A0=C2=A0 #include &lt;p=
thread.h&gt;<br>#endif<br><br></div>With MinGW pthread flavor, _WIN32 is al=
ways defined, and autoconf properly sets the HAVE_PTHREAD macro. Which mean=
s both are defined. The above preprocessor code then includes the Win32 API=
 which is incorrect, causing compile errors. Replacing the whole preprocess=
or block by:<br><br>=C2=A0=C2=A0=C2=A0 #include &lt;pthread.h&gt;<br><br></=
div>In all threading ilmbase source solves the issue.<br><br></div>Would it=
 be possible to patch this? I think that first testing for HAVE_PTHREADS an=
d testing for _WIN32 if the first is not set would solve the issue, without=
 harm to other platforms and compilers. What do you think?<br><br></div>Tha=
nks!<br></div>

--f403045c86964e3bb20561e0d87b--


--===============1269515740014205303==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Openexr-devel mailing list
[email protected]
https://lists.nongnu.org/mailman/listinfo/openexr-devel

--===============1269515740014205303==--