"GNU Ports for eCS Mailing List" <gnuports@2rosenthals.com>
In <list-753514@2rosenthals.com>, on 05/10/20
at 02:15 PM, "Dave Yeo" <gnuports@2rosenthals.com> said:
Hi Dave,
>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.
I know what cmake is, but I've never used cmake myself. However I am
somewhat buzzword compliant after a quick google for
cmake tutorial
I quickly learned that CMakeLists.txt is what the cmake folks decided to
name their makefiles. I am sure they had their reasons.
It is trival for you to check if it is getting defined. No guessing is
required. Add the following to one of your source files:
#if defined(_POSIX_SOURCE)
#error I am defined
#endif
>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.
My current take is that cmake is much like kbuild with different syntax.
>I did
>follow Paul's suggestion and added the definition of _beginthread which
>fixed the issue.
That's a good interim solution.
>Where log2 is wrapped in a __USE_GNU block and defining that before
>including math.h didn't help,
You always fix it the same way you fixed _beginthread. This will work
just fine as long as log2 is implemented and it appears that it is
implemented by kLIBC.
>It's
>frustrating these defines guarding common functions and these are not
>the type of fixes to send upstream.
These guards may be specific to our gcc port. Do the same guards appear
in the pristine gcc sources. From what I've seen investigating your
_beginlibpath, they do not.
I doubt there are any fixes to be sent upsteam to the gcc maintainers.
It's possible that tickets need to be submitted the bww gcc issues tracker
to bring our includes more in sync with what the gcc maintainers consider
current standards.