On Mon, Aug 23, 2021 at 7:13 AM Axel Heider <[email protected]> wrote: > > Grant, > > > ``` > > DeclareCAmkESComponent( > > Platam > > SOURCES ${hacl_sources} > > INCLUDES /usr/lib/gcc-cross/aarch64-linux-gnu/8/include ${hacl_path} > > ${kremlin_path} ${kremlib_path}
Each path given to DeclareCAmkESComponent as an include should end up in the final compilation command unless CMake is doing some magic argument substitutions which a compiler include path could potentially be affected by. If you insert the following 2 lines after DeclareCAmkESRootserver (https://github.com/gjurgensen/attarch/blob/camkes-includes-issue/CMakeLists.txt#L190) you should be able to see whether the include path has made it into the CMake target definition. If the path is in that property, but not in the command line to gcc then the next place to look is in the generated build.ninja file for the Hacl_Chacha20.c.obj build rule to see if the include directory is there. If it isn't in build.ninja, but in the CMake target property, then that indicates that CMake is stripping it out when it generates the ninja build rules. ``` get_target_property(out CAmkESComponent_Platam_instance_platam INCLUDE_DIRECTORIES) message("${out}") ``` > > C_FLAGS -include ${CMAKE_CURRENT_SOURCE_DIR}/hacl_config.h > > ) > > ``` > > > > The problem might be that the build is running in a docker container > that does not have access to your host system. Thus, the absolute > path "/usr/lib/gcc-cross/aarch64-linux-gnu/8/include" to the cross > compiler there cannot be resolved. The current directory where you > invoke the build will be mapped at "/host" in the contianer, so > everything in the tree is accessible. > > Axel > _______________________________________________ > Devel mailing list -- [email protected] > To unsubscribe send an email to [email protected] _______________________________________________ Devel mailing list -- [email protected] To unsubscribe send an email to [email protected]
