Re: Issue when compiling with MinGW and pthreads

Nick Porcino <[email protected]> Wed, 3 Jan 2018 23:49:01 +0000
Newsgroups gmane.comp.video.openexr.devel
Message-ID <CY4PR16MB1670C5DB5C61409ECDEBD256A41E0@CY4PR16MB1670.namprd16.prod.outlook.com>
--===============6899328789778681903==
Content-Language: en-US
Content-Type: multipart/alternative;
	boundary="_000_CY4PR16MB1670C5DB5C61409ECDEBD256A41E0CY4PR16MB1670namp_"

--_000_CY4PR16MB1670C5DB5C61409ECDEBD256A41E0CY4PR16MB1670namp_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

That makes sense to me.

Get Outlook for iOS<https://aka.ms/o0ukef>
________________________________
From: Openexr-devel <[email protected]=
> on behalf of Etienne Sandr=E9-Chardonnal <[email protected]>
Sent: Wednesday, January 3, 2018 7:26:52 AM
To: [email protected]
Subject: [Openexr-devel] Issue when compiling with MinGW and pthreads

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 pa=
ge:

https://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20=
Win32/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 prepro=
cessor 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_PTH=
READS 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!

--_000_CY4PR16MB1670C5DB5C61409ECDEBD256A41E0CY4PR16MB1670namp_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Diso-8859-=
1">
<meta content=3D"text/html; charset=3Dutf-8">
</head>
<body>
<div id=3D"compose-container" itemscope=3D"" itemtype=3D"https://schema.org=
/EmailMessage" style=3D"direction:ltr">
<span itemprop=3D"creator" itemscope=3D"" itemtype=3D"https://schema.org/Or=
ganization"><span itemprop=3D"name"></span></span>
<div>
<div>
<div style=3D"direction:ltr">That makes sense to me.</div>
</div>
<div><br>
</div>
<div class=3D"acompli_signature">Get <a href=3D"https://aka.ms/o0ukef">Outl=
ook for iOS</a></div>
</div>
</div>
<hr tabindex=3D"-1" style=3D"display:inline-block; width:98%">
<div id=3D"divRplyFwdMsg" dir=3D"ltr"><font face=3D"Calibri, sans-serif" co=
lor=3D"#000000" style=3D"font-size:11pt"><b>From:</b> Openexr-devel &lt;ope=
nexr-devel-bounces&#43;[email protected]&gt; on behalf of Et=
ienne Sandr=E9-Chardonnal &lt;[email protected]&gt;<br>
<b>Sent:</b> Wednesday, January 3, 2018 7:26:52 AM<br>
<b>To:</b> [email protected]<br>
<b>Subject:</b> [Openexr-devel] Issue when compiling with MinGW and pthread=
s</font>
<div>&nbsp;</div>
</div>
<div>
<div dir=3D"ltr">
<div>
<div>
<div>
<div>
<div>
<div>
<div>Dear OpenEXR developpers,<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, as shown on the sourceforge download pa=
ge:<br>
<br>
<a href=3D"https://sourceforge.net/projects/mingw-w64/files/Toolchains%20ta=
rgetting%20Win32/Personal%20Builds/mingw-builds/7.2.0/">https://sourceforge=
.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Bu=
ilds/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>
&nbsp;&nbsp;&nbsp; #ifdef NOMINMAX<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; #undef NOMINMAX<br>
&nbsp;&nbsp;&nbsp; #endif<br>
&nbsp;&nbsp;&nbsp; #define NOMINMAX<br>
&nbsp;&nbsp;&nbsp; #include &lt;windows.h&gt;<br>
&nbsp;&nbsp;&nbsp; #include &lt;process.h&gt;<br>
#elif HAVE_PTHREAD<br>
&nbsp;&nbsp;&nbsp; #include &lt;pthread.h&gt;<br>
#endif<br>
<br>
</div>
With MinGW pthread flavor, _WIN32 is always defined, and autoconf properly =
sets the HAVE_PTHREAD macro. Which means both are defined. The above prepro=
cessor code then includes the Win32 API which is incorrect, causing compile=
 errors. Replacing the whole preprocessor
 block by:<br>
<br>
&nbsp;&nbsp;&nbsp; #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_PTH=
READS 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?<br>
<br>
</div>
Thanks!<br>
</div>
</div>
</body>
</html>

--_000_CY4PR16MB1670C5DB5C61409ECDEBD256A41E0CY4PR16MB1670namp_--


--===============6899328789778681903==
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

--===============6899328789778681903==--