Skip to content
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

compiler-rt and libcxx contain reference to TMPDIR [buildpaths] #991

Closed
fidelski opened this issue Aug 6, 2024 · 5 comments
Closed

compiler-rt and libcxx contain reference to TMPDIR [buildpaths] #991

fidelski opened this issue Aug 6, 2024 · 5 comments

Comments

@fidelski
Copy link

fidelski commented Aug 6, 2024

What is happening
In the current master the build of a system that requests CLANGSDK = "1" and adds the following toolchain host tasks:

TOOLCHAIN_HOST_TASK:append = "\
    nativesdk-clang-format \
    nativesdk-clang-tidy \
    nativesdk-clang-tools \
    nativesdk-cmake \
    nativesdk-lldb \
"

fails due to errors relating to QA Issues:

ERROR: compiler-rt-18.1.8-r0 do_package_qa: QA Issue: File /usr/lib/clang/18.1.8/lib/linux/libclang_rt.builtins-powerpc64.a in package compiler-rt-staticdev contains reference to TMPDIR
File /usr/lib/clang/18.1.8/lib/linux/liborc_rt-powerpc64.a in package compiler-rt-staticdev contains reference to TMPDIR [buildpaths]
ERROR: compiler-rt-18.1.8-r0 do_package_qa: Fatal QA errors were found, failing task.
ERROR: Logfile of failure stored in: /mnt/data/yocto/bf133/build/tmp/work/ppc64e5500-vrag-linux/compiler-rt/18.1.8/temp/log.do_package_qa.4021297
ERROR: Task (/mnt/data/yocto/bf133/meta-clang/recipes-devtools/clang/compiler-rt_git.bb:do_package_qa) failed with exit code '1'
ERROR: libcxx-18.1.8-r0 do_package_qa: QA Issue: File /usr/lib64/.debug/libc++abi.so.1.0 in package libcxx-dbg contains reference to TMPDIR
File /usr/lib64/.debug/libc++.so.1.0 in package libcxx-dbg contains reference to TMPDIR [buildpaths]
ERROR: libcxx-18.1.8-r0 do_package_qa: QA Issue: File /usr/lib64/libc++.a in package libcxx-staticdev contains reference to TMPDIR
File /usr/lib64/libc++abi.a in package libcxx-staticdev contains reference to TMPDIR
File /usr/lib64/libc++experimental.a in package libcxx-staticdev contains reference to TMPDIR [buildpaths]
ERROR: libcxx-18.1.8-r0 do_package_qa: Fatal QA errors were found, failing task.
ERROR: Logfile of failure stored in: /mnt/data/yocto/bf133/build/tmp/work/ppc64e5500-vrag-linux/libcxx/18.1.8/temp/log.do_package_qa.4018378
ERROR: Task (/mnt/data/yocto/bf133/meta-clang/recipes-devtools/clang/libcxx_git.bb:do_package_qa) failed with exit code '1'

To Reproduce
Steps to reproduce the behavior:

  1. Use current master of meta-clang
  2. Enter CLANGSDK = "1" in the build configuration
  3. run bitbake {myimage}
  4. The build fails with the error shown

Expected behavior
The build succeeds and the Clang SDK is built correctly.

Seen elsewhere
It seems related or at leas similar to #645

@fidelski
Copy link
Author

fidelski commented Aug 7, 2024

It appears that only files within */.debug are affected. Clang puts its version info with a full path to the binary into the corresponding binary. Eg:

$ strings ./tmp/work/bf133-vrag-linux/vrag-image/1.0/rootfs-dbg/usr/bin/.debug/llvm-ifs | grep -i ${PWD}
clang version 18.1.8 (/mnt/data/yocto/bf133/build/tmp/work-shared/llvm-project-source-18.1.8-r0/llvm-project-18.1.8.src/clang db87ca070c5a4790dcdb9601bcb35037603f6d7f)
.note.gnu.build-id

This is the case for about all the binaries within the .debug subfolder. I guess I am doing something wrong here? I could happily live without those binaries. Is this possible?

@fidelski fidelski changed the title Regression of #645 - compiler-rt and libcxx contain reference to TMPDIR [buildpaths] compiler-rt and libcxx contain reference to TMPDIR [buildpaths] Aug 7, 2024
@kraj
Copy link
Owner

kraj commented Aug 7, 2024

I think we need to find the place in llvm sources where the source path is being emitted into clang -v output it should just emit

clang version 18.1.8

kraj added a commit to YoeDistro/meta-clang that referenced this issue Aug 8, 2024
Fixes Issue kraj#991

If this is not disabled, the build tries to use CMake magic to compute
repository and sha1 its building, however in case of OE it gets it
completely wrong when building from tarball, because its building under
TMPDIR which maybe a directory under main repo checkout e.g. poky tree
so it traverses up and finds the sha of poky and assumes that its building
from a git tree instead of tarball and emits the version control info into
clang -v output e.g.

❯ ../image/mnt/b/yoe/master/build/tmp/work/x86_64-linux/clang-native/20.0.0/recipe-sysroot-native/usr/bin/clang -v
clang version 20.0.0 (/home/kraj/work/llvm-project f133c59b33a749dc6d5fa8fb9a2366b95ea45068)

This can contain buildpaths since work-shared is where llvm sources will be and they
will appear here.

Therefore, avoid cmake trying to do this and we get good clean version info

> ../recipe-sysroot-native/usr/bin/aarch64-yoe-linux/aarch64-yoe-linux-clang
clang version 20.0.0

This will also avoid emitting buildpaths into debuginfo in some cases where
compiler version is emitted into build.id info

Signed-off-by: Khem Raj <[email protected]>
@kraj
Copy link
Owner

kraj commented Aug 8, 2024

@fidelski Are you using tip of master branch or some other branch ? we have recently switched away from building the compiler from git checkout and resorted to tarballs but I see your build is coming out of a git tree which is in TMPDIR

I think cmake's git version and repo url detection logic is getting triggerred and doing unwanted things here

I have a patch here
#993

Please try it out and lemme know.

@fidelski
Copy link
Author

fidelski commented Aug 8, 2024

Thanks a lot for your quick response and patch! I was using tip of master branch, no idea why it should build differently here 🤷‍♂️
Your patch does work, I needed to add -DLLVM_APPEND_VC_REV=OFF to basically all occurrences of EXTRA_OECMAKE though, only setting it in clang_git.bb was not sufficient.

[EDIT] I was too early here - I still get an error regarding to liblldb:

ERROR: nativesdk-clang-18.1.8-r0 do_package_qa: QA Issue: File /usr/local/oe-sdk-hardcoded-buildpath/sysroots/x86_64-pokysdk-linux/usr/lib/liblldb.so.18.1.8 in package nativesdk-liblldb contains reference to TMP
DIR [buildpaths]
ERROR: nativesdk-clang-18.1.8-r0 do_package_qa: Fatal QA errors were found, failing task.
ERROR: Logfile of failure stored in: /mnt/data/yocto/bf133/build/tmp/work/x86_64-nativesdk-pokysdk-linux/nativesdk-clang/18.1.8/temp/log.do_package_qa.349469
ERROR: Task (virtual:nativesdk:/mnt/data/yocto/bf133/meta-clang/recipes-devtools/clang/clang_git.bb:do_package_qa) failed with exit code '1'

This puzzles me, the file inspected is within a path oe-sdk-hardcoded-buildpath and this one does indeed contain some hardcoded path within the build folder (/usr/local/oe-sdk-hardcoded-buildpath/sysroots/x86_64-pokysdk-linux/usr/lib/python3.12/site-packages). But the file at build/tmp/work/ppc64e5500-vrag-linux/clang/18.1.8/packages-split/liblldb/usr/lib64/liblldb.so.18.1.8 does not contain the path. There are some path fragments present though, like ./build-id/, /buildid/(.*)/debuginfo etc. but nothing that corresponds to a path within the build directory. My guess is that those are stripped, but why the other ones are inspected goes beyond my knowledge.

kraj added a commit to YoeDistro/meta-clang that referenced this issue Aug 9, 2024
Fixes Issue kraj#991

If this is not disabled, the build tries to use CMake magic to compute
repository and sha1 its building, however in case of OE it gets it
completely wrong when building from tarball, because its building under
TMPDIR which maybe a directory under main repo checkout e.g. poky tree
so it traverses up and finds the sha of poky and assumes that its building
from a git tree instead of tarball and emits the version control info into
clang -v output e.g.

❯ ../image/mnt/b/yoe/master/build/tmp/work/x86_64-linux/clang-native/20.0.0/recipe-sysroot-native/usr/bin/clang -v
clang version 20.0.0 (/home/kraj/work/llvm-project f133c59b33a749dc6d5fa8fb9a2366b95ea45068)

This can contain buildpaths since work-shared is where llvm sources will be and they
will appear here.

Therefore, avoid cmake trying to do this and we get good clean version info

> ../recipe-sysroot-native/usr/bin/aarch64-yoe-linux/aarch64-yoe-linux-clang
clang version 20.0.0

This will also avoid emitting buildpaths into debuginfo in some cases where
compiler version is emitted into build.id info

Signed-off-by: Khem Raj <[email protected]>
kraj added a commit that referenced this issue Aug 9, 2024
Fixes Issue #991

If this is not disabled, the build tries to use CMake magic to compute
repository and sha1 its building, however in case of OE it gets it
completely wrong when building from tarball, because its building under
TMPDIR which maybe a directory under main repo checkout e.g. poky tree
so it traverses up and finds the sha of poky and assumes that its building
from a git tree instead of tarball and emits the version control info into
clang -v output e.g.

❯ ../image/mnt/b/yoe/master/build/tmp/work/x86_64-linux/clang-native/20.0.0/recipe-sysroot-native/usr/bin/clang -v
clang version 20.0.0 (/home/kraj/work/llvm-project f133c59b33a749dc6d5fa8fb9a2366b95ea45068)

This can contain buildpaths since work-shared is where llvm sources will be and they
will appear here.

Therefore, avoid cmake trying to do this and we get good clean version info

> ../recipe-sysroot-native/usr/bin/aarch64-yoe-linux/aarch64-yoe-linux-clang
clang version 20.0.0

This will also avoid emitting buildpaths into debuginfo in some cases where
compiler version is emitted into build.id info

Signed-off-by: Khem Raj <[email protected]>
@kraj
Copy link
Owner

kraj commented Aug 9, 2024

should be fixed now.

@kraj kraj closed this as completed Aug 9, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants