Questions about some config.log output

[edmundlod]

Hi!

I want to apologise for taking your time for this, but I am hoping to learn!

I went through the config.log file after building the latest commit today. I am using GCC15.1.1 (which is C23) on Linux.

There are a couple of failed (and passed?) tests that caught my eye:

1. res_ninit fails. Yet, when I test this with a simple C programme, it is available on my system. So, in my PKGBUILD I set the following:
   export ac_cv_search_res_ninit="-lresolv"
   Is this the correct way to do this? Why would this fail, if it is available on my system?

2. res_setservers is not available on my system, and I am not sure how to install it. It appears to be used in src/OpenARC/libopenarc/arc-dns.c. Is it necessary to install it?

3. I see the following, where a first test passes, and a second one fails (double parentheses around useconds_t??):

configure:16801: checking for useconds_t
configure:16801: gcc -c -march=native -O2 -pipe -fno-plt -fexceptions         -Wp,-D_FORTIFY_SOURCE=3 -Wformat -Werror=format-security         -fstack-clash-protection -fcf-protection=full         -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -g -ffile-prefix-map=/home/edmund/0data/devel/aur/openarc-git/src=/usr/src/debug/openarc-git  conftest.c >&5
configure:16801: $? = 0
configure:16801: gcc -c -march=native -O2 -pipe -fno-plt -fexceptions         -Wp,-D_FORTIFY_SOURCE=3 -Wformat -Werror=format-security         -fstack-clash-protection -fcf-protection=full         -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -g -ffile-prefix-map=/home/edmund/0data/devel/aur/openarc-git/src=/usr/src/debug/openarc-git  conftest.c >&5
conftest.c: In function 'main':
conftest.c:67:25: error: expected expression before ')' token
   67 | if (sizeof ((useconds_t)))
      |                         ^
configure:16801: $? = 1
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME "OpenARC"
| #define PACKAGE_TARNAME "openarc"
| #define PACKAGE_VERSION "1.2.3pre0"
| #define PACKAGE_STRING "OpenARC 1.2.3pre0"
| #define PACKAGE_BUGREPORT "simta@umich.edu"
| #define PACKAGE_URL ""
| #define PACKAGE "openarc"
| #define VERSION "1.2.3pre0"
| #define HAVE_STDIO_H 1
| #define HAVE_STDLIB_H 1
| #define HAVE_STRING_H 1
| #define HAVE_INTTYPES_H 1
| #define HAVE_STDINT_H 1
| #define HAVE_STRINGS_H 1
| #define HAVE_SYS_STAT_H 1
| #define HAVE_SYS_TYPES_H 1
| #define HAVE_UNISTD_H 1
| #define HAVE_SYS_TIME_H 1
| #define STDC_HEADERS 1
| #define HAVE_DLFCN_H 1
| #define LT_OBJDIR ".libs/"
| #define HAVE_PTHREAD_PRIO_INHERIT 1
| #define HAVE_PTHREAD 1
| #define HAVE_INET_PTON 1
| #define HAVE_INET_NTOP 1
| #define HAVE_GETADDRINFO 1
| #define HAVE_RES_NINIT 1
| #define HAVE_GETOPT_LONG 1
| #define HAVE_SYS_TYPES_H 1
| #define HAVE_NETINET_IN_H 1
| #define HAVE_ARPA_NAMESER_H 1
| #define HAVE_NETDB_H 1
| #define HAVE_RESOLV_H 1
| /* end confdefs.h.  */
| #include <stddef.h>
| #ifdef HAVE_STDIO_H
| # include <stdio.h>
| #endif
| #ifdef HAVE_STDLIB_H
| # include <stdlib.h>
| #endif
| #ifdef HAVE_STRING_H
| # include <string.h>
| #endif
| #ifdef HAVE_INTTYPES_H
| # include <inttypes.h>
| #endif
| #ifdef HAVE_STDINT_H
| # include <stdint.h>
| #endif
| #ifdef HAVE_STRINGS_H
| # include <strings.h>
| #endif
| #ifdef HAVE_SYS_TYPES_H
| # include <sys/types.h>
| #endif
| #ifdef HAVE_SYS_STAT_H
| # include <sys/stat.h>
| #endif
| #ifdef HAVE_UNISTD_H
| # include <unistd.h>
| #endif
| int
| main (void)
| {
| if (sizeof ((useconds_t)))
| 	    return 0;
|   ;
|   return 0;
| }
configure:16801: result: yes

What is happening here, and is there anywhere where this needs to be reported? I don't think an OpenARC test is doing the double parentheses. Is it autotools?

A similar situation happens a bit lower in the config log, with _Bool, uid_t, and a few more.

4. I also see a number of -Wbuiltin-declaration-mismatch warnings. For example:

configure:17236: checking for fork
configure:17236: gcc -o conftest -march=native -O2 -pipe -fno-plt -fexceptions         -Wp,-D_FORTIFY_SOURCE=3 -Wformat -Werror=format-security         -fstack-clash-protection -fcf-protection=full         -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -g -ffile-prefix-map=/home/edmund/0data/devel/aur/openarc-git/src=/usr/src/debug/openarc-git  -Wl,-O1 -Wl,--sort-common -Wl,--as-needed -Wl,-z,relro -Wl,-z,now          -Wl,-z,pack-relative-relocs conftest.c -lresolv  >&5
conftest.c:70:6: warning: conflicting types for built-in function 'fork'; expected 'int(void)' [-Wbuiltin-declaration-mismatch]
   70 | char fork (void);
      |      ^~~~
configure:17236: $? = 0
configure:17236: result: yes

Again, I can't see where either OpenARC, or Autotools declares a 'char fork'. How and where does this happen, and does this need fixing?
Also with isascii, memchr, memmove and others.

I have attached the config.log file for your perusal.

Thank you very much for your reply! I hope that this is not too much of a nuisance!

config.log-for-questions.txt

[flowerysong]

1. res_ninit fails. Yet, when I test this with a simple C programme, it is available on my system.

This is a bug. See #31.

2. res_setservers is not available on my system, and I am not sure how to install it. It appears to be used in src/OpenARC/libopenarc/arc-dns.c. Is it necessary to install it?

If it were necessary to install it, the configure script would fail.

For 3 and 4, you're really getting into the weeds of how the standard autoconf tests work. config.log is very verbose, because it's for investigating errors or digging into when something in the output of the configure script looks wrong. Unless you're familiar with every macro involved (which I certainly am not) it's just a ton of noise to try to read the whole thing.

Compilation/linking tests are not intended to produce idiomatic (or even working) programs, but to determine a specific thing in a portable way. It's expected that they'll produce warnings and that some parts of the test will fail to compile. Unless the result of the check is wrong, you can assume that the autoconf authors know more about C compilers than you and wrote the check that way for a reason.

For example, sizeof (useconds_t) compiling successfully tells us that useconds_t is either a type or a variable; sizeof ((useconds_t)) failing to compile tells us that it's not a variable. So, the result is yes, this type exists.

[edmundlod]

Thank you very much, @flowerysong for the explanations - I finally see the subtle difference in the useconds_t tests! There's much to learn for me still :)