gnuports@2rosenthals.com ?????????????? ????? #6

???: "Dave Yeo" <gnuports@2rosenthals.com> ?? ????
?????????
??: Re: [GNU Ports] _beginthread not declared
??: Sun, 10 May 2020 14:15:31 -0700
??: GNU Ports for eCS Mailing List <gnuports@2rosenthals.com>

On 05/10/20 12:28 PM, Steven Levine wrote:
In <list-752971@2rosenthals.com>, on 05/10/20
   at 06:19 PM, "Paul Smedley" <gnuports@2rosenthals.com> said:

Hi guys,

Yet these turn into a fatal error if I declare __USE_EMX or such.
I remember a similar problem years ago with one port (I forget which).
I worked around it by adding the definition for _beginthread in the .c
file that needed it.
I guessed a bit backwards and the macro priorities.  For _beginthread to
be declared both __STRICT_ANSI__ and _POSIX_SOURCE must be undefined.
Best I can tell this logic is specific to our gcc/kLIBC ports.  The use of
_WITH_UNDERSCORE and __USE_EMX also appear to be specific to our gcc/kLIBC
ports.  __STRICT_ANSI__ is known to gcc and _POSIX_SOURCE is known to the
POSIX standard. _POSIX_SOURCE appears to be deprecated in favor of
_POSIX_C_SOURCE.

One possible solution is to turn off the -ansi option which may allow
_beginthread to be defined without negative side effects.

I thought of that, but I can't find them in the source excepting _POSIX_SOURCE which is in CMakeLists.txt in an EMSCRIPTEN block. Since emscription is a toolchain to build asm.js/WebAssembly, I doubt that it is getting defined.
This is my first visit to a CMake build and I have no idea how to do simple things like make V=1 to get a more informative build and there seems to be one makefile which makes adding stuff like -E hard.
I did follow Paul's suggestion and added the definition of _beginthread which fixed the issue.
Now the build is dying at
K:/work/aom/test/log2_test.cc:38:55: error: 'log2' was not declared in this scope; did you mean 'logl'?
Where log2 is wrapped in a __USE_GNU block and defining that before including math.h didn't help, I guess I should do a make distclean.
It's frustrating these defines guarding common functions and these are not the type of fixes to send upstream.
Dave

--
This email was Anti Virus checked by Astaro Security Gateway. http://www.sophos.com

???????: ????, ??????, ??????.
?????????
??? ????????