-
Notifications
You must be signed in to change notification settings - Fork 444
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Host Path Included in Build Output Causes Yocto Build Failure #1087
Comments
can you check with objdump that the string is actually in a functional part, and not just a comment left by your compiler ? |
this string is not included in .text segment, but stored in .rodata.str1.8 segment only.
my suspection is gfortran add the string into .rodata segment,(see the generated complie command Only detect the xerbla.o included the path that i am not expect. |
I've tried to change SOURCES_64 and SOURCES variables to use paths relative to ${CMAKE_CURRENT_BINARY_DIR} as in:
but unfortunately that's not enough, because CMake will then still convert them to absolute paths as described https://gitlab.kitware.com/cmake/community/-/wikis/FAQ#why-does-cmake-use-full-paths-or-can-i-copy-my-build-tree and it seems to happen with Unix Makefiles as well as Ninja generator (https://gitlab.kitware.com/cmake/cmake/-/issues/13894). I haven't found any way for gfortran not to embed the source file in .rodata (I've tried -fcanon-prefix-map -fdebug-prefix-map -ffile-prefix-map -fno-working-directory -P and whole DEBUG_PREFIX_MAP from Yocto which causes warnings about -fmacro-prefix-map not supported by fortran). As well as -gno-record-gcc-switches from https://gcc.gnu.org/pipermail/fortran/2024-October/061206.html. |
Can anyone please clarify if this is a problem with/for Yocto that did not exist with previous releases of LAPACK (compiled with the same version of gfortran) ? To me this looks as if it is just gfortran (or binutils, linker,...) producing a spurious comment about the original location of the format string in the rodata segment. |
I can confirm the same behavior with "hello world" fortran built with gfortran from Gentoo.
The only Yocto related part is that Yocto enables reproducible builds by default and has QE check which errors out when it finds path to build work directory inside built packages (normally stripped by -fdebug-prefix-map and similar flags, which unfortunately doesn't work for gfortran). https://git.openembedded.org/openembedded-core/commit/meta-selftest/recipes-test/fortran/fortran-helloworld.bb?id=8f1cfaf2be834217cd1cf5be98f44270c36cc31a |
Description
Following the provided CMake build instructions:
Upon inspecting the build.make file, the generated build command appears as follows:
cd /buildarea6/pzha1-cn/upstream/lapack-buil/SRC && /folk/pzha1-cn/homebrew/bin/gfortran $(Fortran_DEFINES) $(Fortran_INCLUDES) $(Fortran_FLAGS) -cpp -c /buildarea6/pzha1-cn/upstream/lapack/SRC/xerbla.f -o CMakeFiles/lapack_obj.dir/xerbla.f.o
Checking the resulting xerbla.f.o file using strings and readelf reveals that the compiled object file contains host paths:
The inclusion of host paths (e.g., /buildarea6/pzha1-cn/upstream/lapack-buil/...) in the .o file leads to a failure in the Yocto build process during the do_package_qa step.
Host paths embedded in object files violate Yocto's reproducibility and deterministic build requirements, causing the build to fail.
Can anyone assist in resolving this issue of host paths being included in the build artifacts? Any guidance or patches to ensure a clean and reproducible build without embedded host-specific paths would be greatly appreciated.
The text was updated successfully, but these errors were encountered: