fatal error: stdlib.h: No such file or directory #include_next <stdlib.h>

VisualGPS commented 4 years ago

Hello Group,

I've been successful in compiling for the Linux desktop (Debian) without issues. However, when I try to compile for the arm, I get a strange error (below) and want to know if anyone has seen this. Hoping that this may be an easy fix.

OS Built with buildroot
using uClibc (also tried glibc)
gcc version /8.4.0

Error Output

[ 52%] Built target json_schema_validator_static
Scanning dependencies of target mdns_static
[ 52%] Building CXX object libs-ext/nmos-cpp/Development/CMakeFiles/mdns_static.dir/mdns/core.cpp.o
In file included from /home/monte/Source/nmos-dev/os/nitrogen7/buildroot/output/host/arm-buildroot-linux-uclibcgnueabihf/sysroot/usr/include/boost/config/platform/linux.hpp:15,
                 from /home/monte/Source/nmos-dev/os/nitrogen7/buildroot/output/host/arm-buildroot-linux-uclibcgnueabihf/sysroot/usr/include/boost/config.hpp:57,
                 from /home/monte/Source/nmos-dev/os/nitrogen7/buildroot/output/host/arm-buildroot-linux-uclibcgnueabihf/sysroot/usr/include/boost/algorithm/string/config.hpp:14,
                 from /home/monte/Source/nmos-dev/os/nitrogen7/buildroot/output/host/arm-buildroot-linux-uclibcgnueabihf/sysroot/usr/include/boost/algorithm/string/predicate.hpp:14,
                 from /home/monte/Source/nmos-dev/software/source/libs-ext/nmos-cpp/Development/mdns/core.h:5,
                 from /home/monte/Source/nmos-dev/software/source/libs-ext/nmos-cpp/Development/mdns/core.cpp:1:
/home/monte/Source/nmos-dev/os/nitrogen7/buildroot/output/host/arm-buildroot-linux-uclibcgnueabihf/include/c++/8.4.0/cstdlib:75:15: fatal error: stdlib.h: No such file or directory
 #include_next <stdlib.h>
               ^~~~~~~~~~

Thanks for the help

TIA

Monte

jwpwh commented 4 years ago

If you run cmake with

-DCMAKE_VERBOSE_MAKEFILE:BOOL=ON

then the actual compile line will be shown and this might give a hint as to what is going on.

VisualGPS commented 4 years ago

Thanks @jwpwh for the reply - I tried the cmake addition and I do see the whole command line as shown below. I'm not sure what I'm looking for here.

[ 52%] Building CXX object libs-ext/nmos-cpp/Development/CMakeFiles/mdns_static.dir/mdns/core.cpp.o
cd /home/monte/Source/nmos-dev/reg-managerBuild/reg-manager_release/libs-ext/nmos-cpp/Development && /home/monte/Source/nmos-dev/os/nitrogen7/buildroot/output/host/usr/bin/arm-buildroot-linux-uclibcgnueabihf-g++  -DBST_SHARED_MUTEX_BOOST -DCPPREST_FORCE_HTTP_CLIENT_ASIO -DCPPREST_FORCE_HTTP_LISTENER_ASIO -DCPPREST_NO_SSL_LEAK_SUPPRESS -DSLOG_LOGGING_SEVERITY=slog::max_verbosity -DSLOG_STATIC -D__STDC_LIMIT_MACROS -I/home/monte/Source/nmos-dev/software/source/libs-ext/nmos-cpp/Development -I/home/monte/Source/nmos-dev/software/source/libs-ext/nmos-cpp/Development/third_party -I/home/monte/Source/nmos-dev/software/source/libs-ext/nmos-cpp/Development/third_party/nlohmann -isystem /home/monte/Source/nmos-dev/os/nitrogen7/buildroot/output/host/arm-buildroot-linux-uclibcgnueabihf/sysroot/usr/include  -Wall -Wstrict-aliasing -fstrict-aliasing -Wextra -Wno-unused-parameter -pedantic -Wno-long-long -O3   -std=c++11 -o CMakeFiles/mdns_static.dir/mdns/core.cpp.o -c /home/monte/Source/nmos-dev/software/source/libs-ext/nmos-cpp/Development/mdns/core.cpp
In file included from /home/monte/Source/nmos-dev/os/nitrogen7/buildroot/output/host/arm-buildroot-linux-uclibcgnueabihf/sysroot/usr/include/boost/config/platform/linux.hpp:15,
                 from /home/monte/Source/nmos-dev/os/nitrogen7/buildroot/output/host/arm-buildroot-linux-uclibcgnueabihf/sysroot/usr/include/boost/config.hpp:57,
                 from /home/monte/Source/nmos-dev/os/nitrogen7/buildroot/output/host/arm-buildroot-linux-uclibcgnueabihf/sysroot/usr/include/boost/algorithm/string/config.hpp:14,
                 from /home/monte/Source/nmos-dev/os/nitrogen7/buildroot/output/host/arm-buildroot-linux-uclibcgnueabihf/sysroot/usr/include/boost/algorithm/string/predicate.hpp:14,
                 from /home/monte/Source/nmos-dev/software/source/libs-ext/nmos-cpp/Development/mdns/core.h:5,
                 from /home/monte/Source/nmos-dev/software/source/libs-ext/nmos-cpp/Development/mdns/core.cpp:1:
/home/monte/Source/nmos-dev/os/nitrogen7/buildroot/output/host/arm-buildroot-linux-uclibcgnueabihf/include/c++/8.4.0/cstdlib:75:15: fatal error: stdlib.h: No such file or directory
 #include_next <stdlib.h>
               ^~~~~~~~~~

jwpwh commented 4 years ago

Did you check the directory to see if the stdlib.h exists?

/home/monte/Source/nmos-dev/os/nitrogen7/buildroot/output/host/arm-buildroot-linux-uclibcgnueabihf/include/c++/8.4.0/cstdlib

Maybe all of the files from the target were not copied up to the buildroot?

rhastie commented 4 years ago

@VisualGPS FWIW - I use qemu-user-static to provide an emulation layer to build my docker containers for ARM32v7 and ARM64... This gives me cross-platform building in a consistent way.

If it helps feel free to download the container (https://hub.docker.com/r/rhastie/nmos-cpp) and grab the executables from inside or alternatively if needed I can add you to the GitHub repo.

VisualGPS commented 4 years ago

@jwpwh,

Did you check the directory to see if the stdlib.h exists?

That's the first item I checked is weather the file existed and it does. To me it looks as this is a toolchain problem, but I've built the rest of the OS and our own embedded modules with success. I'm not too familiar with the use of "#include_next" where this error is generated form.

Scratching my head on this one...

garethsb commented 4 years ago

Looks to me like the -isystem is the problem. See here: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70129

garethsb commented 4 years ago

@VisualGPS, what version of CMake are you using? Looks like there are some fixes related to detection of implicit include dirs in CMake 3.14+. If you're already there, maybe the hints in https://gitlab.kitware.com/cmake/cmake/issues/16919 about using CMAKE_CXX_IMPLICIT_INCLUDE_DIRECTORIES will help...

VisualGPS commented 4 years ago

Update

I'm using Debian 10 on a VM and it sports cmake v3.13 from its default apt repo. I downloaded cmake 3.17, built it and installed it onto my VM. I then reconfigured the nmos build and was able to get by the fatal error: stdlib.h error. Thanks for the CMake suggestion. It looks like a majority of the library built, but it failed on undefined reference to symbol 'TLS_server_method@@OPENSSL_1_1_0' during the ling. I think I can handle that one but suggestions would be welcome.

Cheers

jwpwh commented 4 years ago

I have seen similar error messages with a preceding message about not being able to find a libssl.so file. I ended up using something like:

-DCMAKE_EXE_LINKER_FLAGS_INIT="-L ${RPI_LIBS}/lib -L ${SYSROOT} -Wl,-rpath-link=${SYSROOT}:${OPENSSL_LIB_DIR}:${RPI_LIBS}/lib -latomic"

where OPENSSL_LIB_DIR is defined as the path within the sysroot where the libssl.so.1.1 file is located. The compiler I am using seemed a little sensitive about the order of the -rpath-link directories. The -L options might not be needed but it took me awhile to find a combination which worked and then I stopped messing with it. Your mileage might vary.

If you put an equivalent line in your CMakeLists.txt, then it should be before the project() line.

garethsb commented 4 years ago

Thanks for the help, @jwpwh and @rhastie. With the OpenSSL issue, I wonder why the find_package and target_link_libraries calls aren't resulting in the right library being linked in @VisualGPS environment?

VisualGPS commented 4 years ago

@garethsb-sony CMake configuration seems to find the correct library:

-- Found OpenSSL: /home/monte/Source/nmos-dev/os/nitrogen7/buildroot/output/host/arm-buildroot-linux-gnueabihf/sysroot/usr/lib/libcrypto.so (found version "1.1.1g")

It's during the link process the compiler cannot find the library. I'll take @jwpwh suggestion and give that a try.

Also if there are no objections, I'd like to create a github project that uses buildroot, Raspberry Pi, and uses the sony-nmos as a git submodule. On second thought, a creating a sony-nmos buildroot package would be better. I know that there are notes for the RasPi, but that's with a fully operational Debian (raspian) OS and quite different than a purpose built embedded project. Having an example for the embedded world is quite valuable.

VisualGPS commented 4 years ago

I did not have much luck getting through the link:

undefined reference to symbol 'TLS_server_method@@OPENSSL_1_1_0'

I noted that CMake found OpenSSL:

-- Found OpenSSL: /home/monte/Source/nmos-dev/os/nitrogen7/buildroot/output/host/arm-buildroot-linux-gnueabihf/sysroot/usr/lib/libcrypto.so (found version "1.1.1g")

This version (from buildroot) is OpenSSL 1.1.1g - would this be a problem since the error is showing OpenSSL 1.1.0?

TIA

garethsb commented 4 years ago

I don't think that's the problem. I believe the @@OPENSSL_1_1_0 indicates the release in which that symbol was added.

Can you show us the full link line that failed?

VisualGPS commented 4 years ago

Hi Here is two versions of the link result:

No path modification for openssl link path

[ 92%] Linking CXX executable nmos-cpp-node
cd /home/monte/Source/nmos-dev/reg-managerBuild/reg-manager_release/libs-ext/nmos-cpp/Development && /usr/local/bin/cmake -E cmake_link_script CMakeFiles/nmos-cpp-node.dir/link.txt --verbose=1
/home/monte/Source/nmos-dev/os/nitrogen7/buildroot/output/host/usr/bin/arm-buildroot-linux-gnueabihf-g++   -Wall -Wstrict-aliasing -fstrict-aliasing -Wextra -Wno-unused-parameter -pedantic -Wno-long-long -O3   CMakeFiles/nmos-cpp-node.dir/nmos-cpp-node/main.cpp.o CMakeFiles/nmos-cpp-node.dir/nmos-cpp-node/node_implementation.cpp.o  -o nmos-cpp-node  libnmos-cpp_static.a -lresolv -lstdc++fs /home/monte/Source/nmos-dev/os/nitrogen7/buildroot/output/host/arm-buildroot-linux-gnueabihf/sysroot/usr/lib/libboost_system.so /home/monte/Source/nmos-dev/os/nitrogen7/buildroot/output/host/arm-buildroot-linux-gnueabihf/sysroot/usr/lib/libboost_date_time.so /home/monte/Source/nmos-dev/os/nitrogen7/buildroot/output/host/arm-buildroot-linux-gnueabihf/sysroot/usr/lib/libboost_regex.so /home/monte/Source/nmos-dev/os/nitrogen7/buildroot/output/host/arm-buildroot-linux-gnueabihf/sysroot/usr/lib/libboost_thread.so -lpthread /home/monte/Source/nmos-dev/os/nitrogen7/buildroot/output/host/arm-buildroot-linux-gnueabihf/sysroot/usr/lib/libboost_chrono.so /home/monte/Source/nmos-dev/os/nitrogen7/buildroot/output/host/arm-buildroot-linux-gnueabihf/sysroot/usr/lib/libboost_atomic.so libmdns_static.a /home/monte/Source/nmos-dev/os/nitrogen7/buildroot/output/host/arm-buildroot-linux-gnueabihf/sysroot/usr/lib/libcpprest.so.2.10 -lpthread -ldns_sd libjson_schema_validator_static.a libnmos_is04_schemas_static.a libnmos_is05_schemas_static.a libnmos_is09_schemas_static.a 
/home/monte/Source/nmos-dev/os/nitrogen7/buildroot/output/host/lib/gcc/arm-buildroot-linux-gnueabihf/8.4.0/../../../../arm-buildroot-linux-gnueabihf/bin/ld: libnmos-cpp_static.a(ws_listener_impl.cpp.o): undefined reference to symbol 'TLS_server_method@@OPENSSL_1_1_0'
/home/monte/Source/nmos-dev/os/nitrogen7/buildroot/output/host/lib/gcc/arm-buildroot-linux-gnueabihf/8.4.0/../../../../arm-buildroot-linux-gnueabihf/bin/ld: /home/monte/Source/nmos-dev/os/nitrogen7/buildroot/output/host/arm-buildroot-linux-gnueabihf/sysroot/usr/lib/libssl.so.1.1: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status
make[2]: *** [libs-ext/nmos-cpp/Development/CMakeFiles/nmos-cpp-node.dir/build.make:135: libs-ext/nmos-cpp/Development/nmos-cpp-node] Error 1
make[2]: Leaving directory '/home/monte/Source/nmos-dev/reg-managerBuild/reg-manager_release'
make[1]: *** [CMakeFiles/Makefile2:225: libs-ext/nmos-cpp/Development/CMakeFiles/nmos-cpp-node.dir/all] Error 2
make[1]: Leaving directory '/home/monte/Source/nmos-dev/reg-managerBuild/reg-manager_release'
make: *** [Makefile:153: all] Error 2

Forced added libopenssl path

[ 92%] Linking CXX executable nmos-cpp-node
cd /home/monte/Source/nmos-dev/reg-managerBuild/reg-manager_release/libs-ext/nmos-cpp/Development && /usr/local/bin/cmake -E cmake_link_script CMakeFiles/nmos-cpp-node.dir/link.txt --verbose=1
/home/monte/Source/nmos-dev/os/nitrogen7/buildroot/output/host/usr/bin/arm-buildroot-linux-gnueabihf-g++   -Wall -Wstrict-aliasing -fstrict-aliasing -Wextra -Wno-unused-parameter -pedantic -Wno-long-long -O3  -L /home/monte/Source/nmos-dev/os/buildroot/output/build -Wl,-rpath-link=/home/monte/Source/nmos-dev/os/buildroot/output/build/libopenssl-1.1.1g -latomic CMakeFiles/nmos-cpp-node.dir/nmos-cpp-node/main.cpp.o CMakeFiles/nmos-cpp-node.dir/nmos-cpp-node/node_implementation.cpp.o  -o nmos-cpp-node  libnmos-cpp_static.a -lresolv -lstdc++fs /home/monte/Source/nmos-dev/os/nitrogen7/buildroot/output/host/arm-buildroot-linux-gnueabihf/sysroot/usr/lib/libboost_system.so /home/monte/Source/nmos-dev/os/nitrogen7/buildroot/output/host/arm-buildroot-linux-gnueabihf/sysroot/usr/lib/libboost_date_time.so /home/monte/Source/nmos-dev/os/nitrogen7/buildroot/output/host/arm-buildroot-linux-gnueabihf/sysroot/usr/lib/libboost_regex.so /home/monte/Source/nmos-dev/os/nitrogen7/buildroot/output/host/arm-buildroot-linux-gnueabihf/sysroot/usr/lib/libboost_thread.so -lpthread /home/monte/Source/nmos-dev/os/nitrogen7/buildroot/output/host/arm-buildroot-linux-gnueabihf/sysroot/usr/lib/libboost_chrono.so /home/monte/Source/nmos-dev/os/nitrogen7/buildroot/output/host/arm-buildroot-linux-gnueabihf/sysroot/usr/lib/libboost_atomic.so libmdns_static.a /home/monte/Source/nmos-dev/os/nitrogen7/buildroot/output/host/arm-buildroot-linux-gnueabihf/sysroot/usr/lib/libcpprest.so.2.10 -lpthread -ldns_sd libjson_schema_validator_static.a libnmos_is04_schemas_static.a libnmos_is05_schemas_static.a libnmos_is09_schemas_static.a 
/home/monte/Source/nmos-dev/os/nitrogen7/buildroot/output/host/lib/gcc/arm-buildroot-linux-gnueabihf/8.4.0/../../../../arm-buildroot-linux-gnueabihf/bin/ld: libnmos-cpp_static.a(ws_listener_impl.cpp.o): undefined reference to symbol 'TLS_server_method@@OPENSSL_1_1_0'
/home/monte/Source/nmos-dev/os/nitrogen7/buildroot/output/host/lib/gcc/arm-buildroot-linux-gnueabihf/8.4.0/../../../../arm-buildroot-linux-gnueabihf/bin/ld: /home/monte/Source/nmos-dev/os/nitrogen7/buildroot/output/host/arm-buildroot-linux-gnueabihf/sysroot/usr/lib/libssl.so.1.1: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status
make[2]: *** [libs-ext/nmos-cpp/Development/CMakeFiles/nmos-cpp-node.dir/build.make:135: libs-ext/nmos-cpp/Development/nmos-cpp-node] Error 1
make[2]: Leaving directory '/home/monte/Source/nmos-dev/reg-managerBuild/reg-manager_release'
make[1]: *** [CMakeFiles/Makefile2:225: libs-ext/nmos-cpp/Development/CMakeFiles/nmos-cpp-node.dir/all] Error 2
make[1]: Leaving directory '/home/monte/Source/nmos-dev/reg-managerBuild/reg-manager_release'
make: *** [Makefile:153: all] Error 2

Thanks again for the help.

garethsb commented 4 years ago

We can see that ld actually found the transitive dependency was:

/home/monte/Source/nmos-dev/os/nitrogen7/buildroot/output/host/arm-buildroot-linux-gnueabihf/sysroot/usr/lib/libssl.so.1.1

On the other hand, you tried adding this link path:

/home/monte/Source/nmos-dev/os/buildroot/output/build/libopenssl-1.1.1g

Before working out why the explicit reference to libssl is missing anyway, can you confirm whether adding the first path means the link succeeds?

jwpwh commented 4 years ago

The link line I get when I build the my node (not the nmos-cpp-node, but my node based on nmos-cpp-node) includes arguments like the following

/home/myhome/project/3rdparty/install-nmos/linux-raspi/lib/libssl.so /home/myhome/project/3rdparty/install-nmos/linux-raspi/lib/libcrypto.a

I believe the libssl.so has the symbol TLS_server_method. The error message from your link seems to imply that a Dynamic Shared Object is missing from the command line. So it seems like the question is how to get these entries on your link line.

I am not sure exactly how these arguments get added to the command line. Part of the magic of cmake it seems. Seems to be mentioned in lib/pkgconfig/openssl.pc.

Your link line had libopenssl-1.1.1g mentioned as part of -rpath-link. I thought -rpath-link was like -L where the argument is a directory containing libraries but not names of libraries to include. I believe the library name should be listed on the command line like the object files or a '-l' option.

garethsb commented 4 years ago

Yes, exactly, what @jwpwh says!

VisualGPS commented 4 years ago

Update

I have it building using Buildroot. 😎 It seems to be a kernel issue on my part. Investigating further.

I've started a github project that will build a custom Linux Kernel, build the file system, and the sony-nmos libraries for the Raspberry Pi 3. I'm not done with the project, but it does build an OS and you can copy the nmos-cpp-node, registry to the target and it runs. I still need to create an install and add documentation.

The project is located: sony-nmos-buildroot

I think this issue can be closed. Also thank you for all of the suggestions and help.

🍻

Muzad commented 3 years ago

hi I had this problem too while compiling for the arm. and finally i solved it by this cmake variable: -DCMAKE_NO_SYSTEM_FROM_IMPORTED=1

(however it was okay without this cmake variable too while building by my yocto recipe file)

ElectricRCAircraftGuy commented 1 year ago

hi I had this problem too while compiling for the arm. and finally i solved it by this cmake variable: -DCMAKE_NO_SYSTEM_FROM_IMPORTED=1

(however it was okay without this cmake variable too while building by my yocto recipe file)

@Muzad , thank you. I don't understand what that define really does, but it seems to work for me on Buildroot to build grpc. See my answer and full details here: Buildroot: CMake: arch64-none-linux-gnu/include/c++/9.2.1/cstdlib:75:15: fatal error: stdlib.h: No such file or directory while building grpc package

sony / nmos-cpp