oneapi-src
Fatal error: stdlib.h: No such file or directory from #include_next <stdlib.h>
Describe the bug Fatal error when building:
In file included from /usr/include/c++/13.2.1/bits/stl_algo.h:71,
from /usr/include/c++/13.2.1/algorithm:61,
from cpp/oneapi/dal/algo/logistic_regression/parameters/cpu/train_parameters.cpp:17:
/usr/include/c++/13.2.1/cstdlib:79:15: fatal error: stdlib.h: No such file or directory
79 | #include_next <stdlib.h>
| ^~~~~~~~~~
compilation terminated.
To Reproduce Steps to reproduce the behavior:
cd src/oneDAL-2024.1.0
./dev/download_micromkl.sh
LIBRARY_PATH=/usr/lib \
LD_LIBRARY_PATH=/usr/lib \
TBBROOT=/usr \
make -f makefile daal oneapi_c -j10 COMPILER=gnu PLAT=lnx32e REQCPU="avx2 avx512"
Expected behavior It should build successfully
Diagnosis and Fix The problem first occurs at this step:
g++ -m64 -fwrapv -fno-strict-overflow -fno-delete-null-pointer-checks -Werror -Wreturn-type -Wno-error=dangling-reference -c -Wformat -Wformat-security -O2 -D_FORTIFY_SOURCE=2 -fstack-protector-strong -fPIC -std=c++17 -DTBB_SUPPRESS_DEPRECATED_MESSAGES -D__TBB_LEGACY_MODE -pedantic -Wall -Wextra -Wno-unused-parameter -DDAAL_NOTHROW_EXCEPTIONS -DDAAL_HIDE_DEPRECATED -D_ENABLE_ATOMIC_ALIGNMENT_FIX -D__ONEDAL_ENABLE_DLL_EXPORT__ -D__TBB_NO_IMPLICIT_LINKAGE -DTBB_USE_ASSERT=0 @./__work_gnu/md/lnx32e/oneapi_dynamic/inc_y_folders.txt -MMD -MT __work_gnu/md/lnx32e/oneapi_dynamic/cpp-oneapi-dal-algo-logistic_regression-parameters-cpu-train_parameters.o -MF __work_gnu/md/lnx32e/oneapi_dynamic/cpp-oneapi-dal-algo-logistic_regression-parameters-cpu-train_parameters.o.d.tmp -o__work_gnu/md/lnx32e/oneapi_dynamic/cpp-oneapi-dal-algo-logistic_regression-parameters-cpu-train_parameters.o cpp/oneapi/dal/algo/logistic_regression/parameters/cpu/train_parameters.cpp && sed -n -i -e ':beg' -e '/\\$/N; s/\\\n/ /; tbeg' -e ' s@cpp/oneapi/dal/algo/logistic_regression/parameters/cpu/train_parameters.cpp\( \|$\)@@; s/ */ /g; s/^.*: *$//;' -e 's@ /[^ ][^ ]*@ @g; s/^.*: *$//;' -e '/./{ p; s/^.*://; s/^ *//; /./{ s/ *$/:/; s/ */:\n/g; p; };}' __work_gnu/md/lnx32e/oneapi_dynamic/cpp-oneapi-dal-algo-logistic_regression-parameters-cpu-train_parameters.o.d.tmp && printf '\n%s\n' '__work_gnu/md/lnx32e/oneapi_dynamic/cpp-oneapi-dal-algo-logistic_regression-parameters-cpu-train_parameters.o.mkdeps += makefile dev/make/cmplr.gnu.mkl.mk dev/make/cmplr.dpcpp.mk dev/make/common.mk dev/make/deps.mk dev/make/deps.mkl.mk makefile.ver' '$(__work_gnu/md/lnx32e/oneapi_dynamic/cpp-oneapi-dal-algo-logistic_regression-parameters-cpu-train_parameters.o.mkdeps):' '__work_gnu/md/lnx32e/oneapi_dynamic/cpp-oneapi-dal-algo-logistic_regression-parameters-cpu-train_parameters.o: $(__work_gnu/md/lnx32e/oneapi_dynamic/cpp-oneapi-dal-algo-logistic_regression-parameters-cpu-train_parameters.o.mkdeps)' '__work_gnu/md/lnx32e/oneapi_dynamic/cpp-oneapi-dal-algo-logistic_regression-parameters-cpu-train_parameters.o.trigger = g++ -m64 -fwrapv -fno-strict-overflow -fno-delete-null-pointer-checks -Werror -Wreturn-type -Wno-error=dangling-reference -c -Wformat -Wformat-security -O2 -D_FORTIFY_SOURCE=2 -fstack-protector-strong -fPIC -std=c++17 -DTBB_SUPPRESS_DEPRECATED_MESSAGES -D__TBB_LEGACY_MODE -pedantic -Wall -Wextra -Wno-unused-parameter -DDAAL_NOTHROW_EXCEPTIONS -DDAAL_HIDE_DEPRECATED -D_ENABLE_ATOMIC_ALIGNMENT_FIX -D__ONEDAL_ENABLE_DLL_EXPORT__ -D__TBB_NO_IMPLICIT_LINKAGE -DTBB_USE_ASSERT=0 @./__work_gnu/md/lnx32e/oneapi_dynamic/inc_y_folders.txt -o__work_gnu/md/lnx32e/oneapi_dynamic/cpp-oneapi-dal-algo-logistic_regression-parameters-cpu-train_parameters.o cpp/oneapi/dal/algo/logistic_regression/parameters/cpu/train_parameters.cpp' >> __work_gnu/md/lnx32e/oneapi_dynamic/cpp-oneapi-dal-algo-logistic_regression-parameters-cpu-train_parameters.o.d.tmp && mv -f __work_gnu/md/lnx32e/oneapi_dynamic/cpp-oneapi-dal-algo-logistic_regression-parameters-cpu-train_parameters.o.d.tmp __work_gnu/md/lnx32e/oneapi_dynamic/cpp-oneapi-dal-algo-logistic_regression-parameters-cpu-train_parameters.o.d
which results in the above fatal error. We can see the reason for this by adding -v to the g++ command. It reports:
#include "..." search starts here:
#include <...> search starts here:
./cpp
./__release_lnx_gnu/daal/latest/include
./cpp/daal
./__work_gnu/md/lnx32e
./__deps/mklfpk/include
./__deps/mklfpk/lnx/include
./__deps/mklgpufpk/lnx/include
/usr/include/tbb
/usr/include
/usr/lib/gcc/x86_64-pc-linux-gnu/13.2.1/../../../../include/c++/13.2.1
/usr/lib/gcc/x86_64-pc-linux-gnu/13.2.1/../../../../include/c++/13.2.1/x86_64-pc-linux-gnu
/usr/lib/gcc/x86_64-pc-linux-gnu/13.2.1/../../../../include/c++/13.2.1/backward
/usr/lib/gcc/x86_64-pc-linux-gnu/13.2.1/include
/usr/local/include
/usr/lib/gcc/x86_64-pc-linux-gnu/13.2.1/include-fixed
End of search list.
From the error message:
/usr/include/c++/13.2.1/cstdlib:79:15: fatal error: stdlib.h: No such file or directory
79 | #include_next <stdlib.h>
| ^~~~~~~~~~
In context, that line in /usr/include/c++/13.2.1/cstdlib is:
// Need to ensure this finds the C library's <stdlib.h> not a libstdc++
// wrapper that might already be installed later in the include search path.
#define _GLIBCXX_INCLUDE_NEXT_C_HEADERS
#include_next <stdlib.h>
#undef _GLIBCXX_INCLUDE_NEXT_C_HEADERS
What should happen is that stdlib.h is included from /usr/include. However since /usr/include precedes /usr/lib/gcc/x86_64-pc-linux-gnu/13.2.1/../../../../include/c++/13.2.1 in the above #include <...> search paths, it doesn't find it, resulting in the error.
The source of how these #include <...> search paths got mixed up is from @./__work_gnu/md/lnx32e/oneapi_dynamic/inc_y_folders.txt which is in the above g++ command:
cat __work_gnu/md/lnx32e/oneapi_dynamic/inc_y_folders.txt
-I./cpp -isystem./__release_lnx_gnu/daal/latest/include -isystem./cpp/daal -isystem./__work_gnu/md/lnx32e -isystem./__deps/mklfpk/include -isystem./__deps/mklfpk/lnx/include -isystem./__deps/mklgpufpk/lnx/include -isystem/usr/include/tbb -isystem/usr/include
Note the last parameter -isystem/usr/include. By simply excluding this from the inc_a_folders.txt and inc_y_folders.txt generated files fixes the problem. Making this change results in /usr/include coming correctly after /usr/include/c++/13.2.1 in the #include <...> search paths.
Environment:
- OS: Arch Linux (2024 April 2)
- Compiler: gcc (GCC) 13.2.1 20230801
- Version: 2024.1.0
Hello @mattpulver ,
We've tried to reproduce the issue with all the software versions as reported except Arch Linux though with no luck. Did you have any progress on your side meanwhile?
Yes I'm able to get through this by adding
awk '{print} /\(ONEAPI\.include_options\)/{print "\tsed -i \x27s# -isystem/usr/include$$##\x27 $@"}' \
makefile > makefile.tmp && mv makefile.tmp makefile
to the prepare() step in the PKGBUILD file.
I haven't tracked down where the /usr/include entry is coming from that appears in the intermediate inc_[ay]_folders.txt files but I think this would be fixed if they were omitted. I'm not sure why they need to be included, as they seem to mess up
#include_next <stdlib.h>
in cstdlib: https://github.com/gcc-mirror/gcc/blob/cacc55a4c0be8d0bc7417b6a28924eadbbe428e3/libstdc%2B%2B-v3/include/c_global/cstdlib#L79