Mailing List gnuports@2rosenthals.com Archived Message #7

From: "Steven Levine" <gnuports@2rosenthals.com> Full Headers
Undecoded message
Subject: Re: [GNU Ports] _beginthread not declared
Date: Sun, 10 May 2020 21:21:41 -0700
To: "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.

  https://cliutils.gitlab.io/modern-cmake/chapters/features/debug.html

describes som edebugging techniques.

  https://stackoverflow.com/questions/10085945/set-cflags-and-cxxflags-options-using-cmake

seems to explain how to add values to CFLAGS

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.

Steven

--
----------------------------------------------------------------------
"Steven Levine" <steve53@earthlink.net>  Warp/DIY/BlueLion etc.
www.scoug.com www.arcanoae.com www.warpcave.com
----------------------------------------------------------------------


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

Subscribe: Feed, Digest, Index.
Unsubscribe
Mail to ListMaster