Host Path Included in Build Output Causes Yocto Build Failure

[surainbow]

Description
Following the provided CMake build instructions:

mkdir build
cd build
cmake -DCMAKE_INSTALL_PREFIX=$HOME/.local/lapack ..
cmake --build . -j --target install

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:

$strings BLAS/SRC/CMakeFiles/blas_64_obj.dir/blas_64_obj/xerbla.f.o | grep buildarea6
/buildarea6/pzha1-cn/upstream/lapack-buil/BLAS/SRC/blas_64_obj/xerbla.f

$readelf -x .rodata.str1.8 BLAS/SRC/CMakeFiles/blas_64_obj.dir/blas_64_obj/xerbla.f.o
Hex dump of section '.rodata.str1.8':
  0x00000000 2f627569 6c646172 6561362f 707a6861 /buildarea6/pzha
  0x00000010 312d636e 2f757073 74726561 6d2f6c61 1-cn/upstream/la
  0x00000020 7061636b 2d627569 6c2f424c 41532f53 pack-buil/BLAS/S
  0x00000030 52432f62 6c61735f 36345f6f 626a2f78 RC/blas_64_obj/x
  0x00000040 6572626c 612e6600 28202720 2a2a204f erbla.f.( ' ** O
  0x00000050 6e20656e 74727920 746f2027 2c20412c n entry to ', A,
  0x00000060 20272070 6172616d 65746572 206e756d  ' parameter num
  0x00000070 62657220 272c2049 322c2027 20686164 ber ', I2, ' had
  0x00000080 20272c20 20202020 20202761 6e20696c  ',       'an il
  0x00000090 6c656761 6c207661 6c756527 202900   legal value' ).

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.

[martin-frbg]

can you check with objdump that the string is actually in a functional part, and not just a comment left by your compiler ?

[surainbow]

this string is not included in .text segment, but stored in .rodata.str1.8 segment only.

❯ objdump -d BLAS/SRC/CMakeFiles/blas_64_obj.dir/blas_64_obj/xerbla.f.o
BLAS/SRC/CMakeFiles/blas_64_obj.dir/blas_64_obj/xerbla.f.o:     file format elf64-x86-64
Disassembly of section .text:
0000000000000000 <xerbla_64_>:
   0:   41 55                   push   %r13
   2:   48 8d 05 00 00 00 00    lea    0x0(%rip),%rax        # 9 <xerbla_64_+0x9>
   9:   49 89 d5                mov    %rdx,%r13
   c:   41 54                   push   %r12
   e:   49 89 f4                mov    %rsi,%r12
  11:   55                      push   %rbp
  12:   48 89 fd                mov    %rdi,%rbp
  15:   53                      push   %rbx
  16:   48 81 ec 18 02 00 00    sub    $0x218,%rsp
  1d:   48 89 44 24 08          mov    %rax,0x8(%rsp)
  22:   48 8d 05 00 00 00 00    lea    0x0(%rip),%rax        # 29 <xerbla_64_+0x29>
  29:   48 89 e7                mov    %rsp,%rdi
  2c:   48 89 44 24 50          mov    %rax,0x50(%rsp)
  31:   48 8b 05 00 00 00 00    mov    0x0(%rip),%rax        # 38 <xerbla_64_+0x38>
  38:   c7 44 24 10 4d 00 00    movl   $0x4d,0x10(%rsp)
  3f:   00
  40:   48 89 04 24             mov    %rax,(%rsp)
  44:   48 c7 44 24 58 56 00    movq   $0x56,0x58(%rsp)
  4b:   00 00
  4d:   e8 00 00 00 00          call   52 <xerbla_64_+0x52>
  52:   48 89 ee                mov    %rbp,%rsi
  55:   4c 89 ef                mov    %r13,%rdi
  58:   e8 00 00 00 00          call   5d <xerbla_64_+0x5d>
  5d:   31 d2                   xor    %edx,%edx
  5f:   48 89 ee                mov    %rbp,%rsi
  62:   48 89 e7                mov    %rsp,%rdi
  65:   48 85 c0                test   %rax,%rax
  68:   48 0f 49 d0             cmovns %rax,%rdx
  6c:   e8 00 00 00 00          call   71 <xerbla_64_+0x71>
  71:   ba 08 00 00 00          mov    $0x8,%edx
  76:   4c 89 e6                mov    %r12,%rsi
  79:   48 89 e7                mov    %rsp,%rdi
  7c:   e8 00 00 00 00          call   81 <xerbla_64_+0x81>
  81:   48 89 e7                mov    %rsp,%rdi
  84:   e8 00 00 00 00          call   89 <xerbla_64_+0x89>
  89:   31 d2                   xor    %edx,%edx
  8b:   31 f6                   xor    %esi,%esi
  8d:   31 ff                   xor    %edi,%edi
  8f:   e8 00 00 00 00          call   94 <.LC1+0x4c>

❯ objdump -s -j .rodata.str1.8 BLAS/SRC/CMakeFiles/blas_64_obj.dir/blas_64_obj/xerbla.f.o
BLAS/SRC/CMakeFiles/blas_64_obj.dir/blas_64_obj/xerbla.f.o:     file format elf64-x86-64
Contents of section .rodata.str1.8:
 0000 2f627569 6c646172 6561362f 707a6861  /buildarea6/pzha
 0010 312d636e 2f757073 74726561 6d2f6c61  1-cn/upstream/la
 0020 7061636b 2d627569 6c2f424c 41532f53  pack-buil/BLAS/S
 0030 52432f62 6c61735f 36345f6f 626a2f78  RC/blas_64_obj/x
 0040 6572626c 612e6600 28202720 2a2a204f  erbla.f.( ' ** O
 0050 6e20656e 74727920 746f2027 2c20412c  n entry to ', A,
 0060 20272070 6172616d 65746572 206e756d   ' parameter num
 0070 62657220 272c2049 322c2027 20686164  ber ', I2, ' had
 0080 20272c20 20202020 20202761 6e20696c   ',       'an il
 0090 6c656761 6c207661 6c756527 202900    legal value' ).
❯ objdump -h BLAS/SRC/CMakeFiles/blas_64_obj.dir/blas_64_obj/xerbla.f.o
BLAS/SRC/CMakeFiles/blas_64_obj.dir/blas_64_obj/xerbla.f.o:     file format elf64-x86-64
Sections:
Idx Name          Size      VMA               LMA               File off  Algn
  0 .text         00000094  0000000000000000  0000000000000000  00000040  2**4
                  CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
  1 .data         00000000  0000000000000000  0000000000000000  000000d4  2**0
                  CONTENTS, ALLOC, LOAD, DATA
  2 .bss          00000000  0000000000000000  0000000000000000  000000d4  2**0
                  ALLOC
  3 .rodata.str1.8 0000009f  0000000000000000  0000000000000000  000000d8  2**3
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  4 .rodata.cst8  00000008  0000000000000000  0000000000000000  00000178  2**3
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  5 .comment      00000023  0000000000000000  0000000000000000  00000180  2**0
                  CONTENTS, READONLY
  6 .note.GNU-stack 00000000  0000000000000000  0000000000000000  000001a3  2**0
                  CONTENTS, READONLY
  7 .eh_frame     00000048  0000000000000000  0000000000000000  000001a8  2**3
                  CONTENTS, ALLOC, LOAD, RELOC, READONLY, DATA

my suspection is gfortran add the string into .rodata segment,(see the generated complie command "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-buil/BLAS/SRC/blas_64_obj/xerbla.f -o CMakeFiles/lapack_obj.dir/xerbla.f.o"), when i try to compile the manually by using relevant path, the relevant path stored in .rodata segement.

Only detect the xerbla.o included the path that i am not expect.