Compile error in affinity.c

[DusanJovic-NOAA]

Describe the bug
I am building FMS (as part of ufs-weather-model) on Ubuntu 19.10. I get this error:

/home/dusan/simple-ufs/src/model/FMS/affinity/affinity.c:31:14: error: static declaration of ‘gettid’ follows non-static declaration
   31 | static pid_t gettid(void)
      |              ^~~~~~
In file included from /usr/include/unistd.h:1170,
                 from /home/dusan/simple-ufs/src/model/FMS/affinity/affinity.c:24:
/usr/include/x86_64-linux-gnu/bits/unistd_ext.h:34:16: note: previous declaration of ‘gettid’ was here
   34 | extern __pid_t gettid (void) __THROW;
      |                ^~~~~~
make[2]: *** [CMakeFiles/fms.dir/build.make:1077: CMakeFiles/fms.dir/FMS/affinity/affinity.c.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:345: CMakeFiles/fms.dir/all] Error 2
make: *** [Makefile:152: all] Error 2

We use FMS tag 2019.01.01

To Reproduce
Build FMS on Ubuntu 19.10

Expected behavior
Compile without error

System Environment
Describe the system environment, include:

• OS: Linux, Ubuntu 19.10
• Compiler(s): gcc 9.2.1
• MPI type, and version mpich3
• netCDF Version: netcdf-c 4.7.3 netcdf-fortran 4.5.2
• Configure options: Any additional flags, or macros passed to configure

[marshallward]

There's more info about this issue here: #196

The short answer is that Linux defines its own gettid with an incompatible header, but this seems to only be an issue on newer Linux environments (perhaps GCC 9.x or a newer libc).

It's been solved in the mainline repository by running autotools (i.e. ./configure ; make) which conditionally sets the -DHAVE_GETTID directive.

But if (like me) you're not yet using the new autotools build system, then you can temporarily solve the problem by deleting the static keyword.

[DusanJovic-NOAA]

Thank you @marshallward. And thanks for pointing to that issue. Yes removing static keyword solved the problem, temporarily. Since in UFS we pull FMS as a submodule and compile it using UFS's cmake (or gnu make) build. We do not use autotools.

Just curious, why do you think definition of gettid header in Linux is incompatible? It looks like it was introduced in glibc 2.30 ( https://lwn.net/Articles/795127/ ) which is exactly the version distributed in Ubuntu 19.10

$ /usr/lib/x86_64-linux-gnu/libc.so.6
GNU C Library (Ubuntu GLIBC 2.30-0ubuntu2) stable release version 2.30.
Copyright (C) 2019 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
Compiled by GNU CC version 9.2.1 20190909.
libc ABIs: UNIQUE IFUNC ABSOLUTE
For bug reporting instructions, please see:
<https://bugs.launchpad.net/ubuntu/+source/glibc/+bugs>.

[marshallward]

I think you may have solved the mystery: the system call has been around for ages (which is why I had been confused) but the interface was only recently added to GNU libc. I also noticed this on the manpage:

VERSIONS
The gettid() system call first appeared on Linux in kernel 2.4.11. Library support was added in glibc 2.30. (Earlier glibc versions did not provide a wrapper for this system call, necessitating the use of syscall(2).)

As for the error, I think it's just an incompatible header. If you have a generic header like this:

int foo(void);  // e.g. from some #include <...>
static int foo() { return 0; }

then you get an error. I suppose one reason for the error is to avoid logical inconsistency, since static literally means that the function is only defined within the file, whereas using a non-static header implies that it could be defined outside of the file.

[wrongkindofdoctor]

Thank you, @marshallward for pointing @DusanJovic-NOAA toward the related issue, and for clarifying possible reasons for the error.