https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91694
--- Comment #6 from Rishi Khan <ri...@extreme-scale.com> ---
(In reply to Jakub Jelinek from comment #5)
> > It seems like libgomp's configure.ac is already using AC_LINK_IFELSE for all
> > OS's around line 241 to 'Check for pthread_{,attr_}[sg]etaffinity_np.'.
>
> True, but that is something most of the targets don't have, it is glibc
> specific mostly, so doesn't matter if it fails.
>
> > In my newlib startup setup, I only build libgomp in stage2.
> > See here for Makefile:
> > https://github.com/riscv/riscv-gnu-toolchain/blob/master/Makefile.in
> > On line 541 I have --enable-threads and on line 551 I have --enable-libgomp
>
> Your OS isn't among those where libgomp is supported.
This may be the case. It worked fine in gcc-7.3 but when we upgraded it failed
due to these configure errors.
> Do you say you have POSIX threads but not gethostname?
Yes. There is no real reason we don't have gethostname beyond the fact that we
didn't implement it yet.
Why is it the case that libgomp checks to see if it has gethostname by
compiling a program that has gethostname but not linking it? Regardless of if
the OS supports or is does not support gethostname, just compiling it will
succeed. [same for uname and getpid]
Here are some more examples where it tries to link to check if a function
exists:
# Check for functions needed. (line 219 of configure.ac,
AC_CHECK_FUNCS(getloadavg clock_gettime strtoull)
AC_CHECK_FUNCS(aligned_alloc posix_memalign memalign _aligned_malloc)
in configure, AC_CHECK_FUNCS resolves to calls to ac_fn_c_check_func (line
15811), which calls ac_fn_c_try_link (line 1867)
