fatal error: config.h: No such file or directory

[silabs-robin]

As I follow the build instructions, configure does not seem to create config.h (even though it says it does).

$ ../configure --prefix=$RISCV
checking build system type... x86_64-pc-linux-gnu
checking host system type... x86_64-pc-linux-gnu
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking for g++... g++
checking whether we are using the GNU C++ compiler... yes
checking whether g++ accepts -g... yes
checking for ar... ar
checking for ranlib... ranlib
checking for dtc... /designtools/utils_prod/bin/dtc
checking how to run the C++ preprocessor... g++ -E
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking whether byte ordering is bigendian... no
checking for a BSD-compatible install... /bin/install -c
checking for ANSI C header files... (cached) yes
checking for __int128_t... yes
checking whether the linker accepts -Wl,--export-dynamic... yes
checking whether C++ compiler accepts -relocatable-pch... no
configure: configuring default subproject : fesvr
checking for pthread_create in -lpthread... yes
checking for struct statx.stx_ino... yes
checking for struct statx.stx_mnt_id... no
configure: configuring default subproject : riscv
checking for boostlib >= 1.53 (105300)... configure: We could not detect the boost libraries (version 1.53 or
 higher). If you have a staged boost library (still not installed) please specify $BOOST_ROOT in your environ
ment and do not give a PATH to --with-boost option.  If you are sure you have boost installed, then check you
r version number looking in <boost/version.hpp>. See http://randspringer.de/boost for more documentation.
checking whether the Boost::ASIO library is available... no
checking whether the Boost::Regex library is available... no
checking for main in -lboost_system... no
checking for main in -lboost_regex... no
checking for library containing dlopen... -ldl
checking for pthread_create in -lpthread... (cached) yes
configure: configuring default subproject : disasm
configure: configuring default subproject : customext
configure: configuring default subproject : fdt
configure: configuring default subproject : softfloat
configure: configuring default subproject : spike_main
configure: configuring default subproject : spike_dasm
configure: creating ./config.status
config.status: creating fesvr.mk
config.status: creating riscv.mk
config.status: creating disasm.mk
config.status: creating customext.mk
config.status: creating fdt.mk
config.status: creating softfloat.mk
config.status: creating spike_main.mk
config.status: creating spike_dasm.mk
config.status: creating Makefile
config.status: creating riscv-fesvr.pc
config.status: creating riscv-disasm.pc
config.status: creating config.h
config.status: config.h is unchanged

$ make
g++ -MMD -MP  -DPREFIX=\"/work/hefegran/binutils/corev-openhw-gcc-centos7-20230310\" -Wall -Wno-unused -Wno-n
onportable-include-path -g -O2 -fPIC -DSPIKE_HASH_VERSION=0x8e8a6373 -g -O2 -DPREFIX=\"/work/hefegran/binutil
s/corev-openhw-gcc-centos7-20230310\" -Wall -Wno-unused -Wno-nonportable-include-path -g -O2 -fPIC -DSPIKE_HA
SH_VERSION=0x8e8a6373 -std=c++17 -g -O2   -I. -I.. -I../fesvr -I../riscv -I../disasm -I../customext -I../fdt
-I../softfloat -I../spike_main -I../spike_dasm -I/include -I//tool/questasim/2021.2_1/include -I/include -I/s
hare/verilator/include/vltstd/ -I/include/boost-0   -c ../fesvr/elfloader.cc
../fesvr/elfloader.cc:3:10: fatal error: config.h: No such file or directory
    3 | #include "config.h"
      |          ^~~~~~~~~~
compilation terminated.
make: *** [Makefile:349: elfloader.o] Error 1

$ cd ..
$ find | grep config.h
./config.h.in

[aswaterman]

Never seen this one before, but is there any chance you are running configure from within a directory that is not completely empty? Have you tried blowing away the directory, recreating it, and rerunning?

[silabs-robin]

Hi.

[...] is there any chance you are running configure from within a directory that is not completely empty? Have you tried blowing away the directory, recreating it, and rerunning?

$ cd riscv-isa-sim/

$ git reset . ; git checkout . ; git clean -xdff .
Updated 0 paths from the index
Removing build/

$ mkdir build

$ cd build/

$ ../configure --prefix=`pwd`

$ make

^ results in the same problem.

(Right now I just used pwd for the prefix, but I don't think that could affect the generation of config.h?)

[aswaterman]

Setting the prefix to be the build directory seems highly suspicious to me.

[silabs-robin]

git clean -xdff .
../configure --prefix=/work/ropeders/tmp/spike/
make

This also results in the same problem.

[aswaterman]

Mysterious.

Since you're the only person to have reported this, and we can't reproduce it, I think it's up to you to figure it out. Let us know what you find.

[silabs-robin]

[...] Let us know what you find.

According to this stackoverflow post, the most likely culprit is a missing libconfig package.

As I'm not "in control" of the server I'm working on (no admin rights), I cannot confirm this. But I managed to bypass the problem by using a server node with an older version of the OS we're running, which presumably has this package installed.

One final question before closing this ticket: The configure script currently does not reflect that it failed to create config.h, and the rest of the build system seems to be unaware of the failure and continues blindly. Should that be fixed, or is it assumed to be such a rare problem that it is deemed don't-care?

[aswaterman]

According to this stackoverflow post, the most likely culprit is a missing libconfig package.

Ack. Thanks for getting your hands dirty on this one.

Should that be fixed, or is it assumed to be such a rare problem that it is deemed don't-care?

If there's a simple way to issue a helpful error message that fits within the autoconf framework, then we'd of course appreciate a PR. But I do think it's pretty rare, so if the fix is lengthy or otherwise awkward, then it might be best to leave it alone.

[silabs-robin]

Ok :) Thank you very much for your time, then, @aswaterman. I consider this resolved and am closing the ticket now.