QA Issue: File xxx.c in package xxx-project contains reference to TMPDIR
Opened this issue · 8 comments
Hi all,
I encounter so many QA issues about contains reference to TMPDIR, and I can use WARN_QA:remove = "buildpaths" disable this warning message, but I'm still curious about this issue.
I tried tracking down the issue and came to the following conclusions, but not sure if is it right or not.
I check this guideline
This check ensures that build system paths (including TMPDIR) do not appear in output files, which not only leaks build system configuration into the target, but also hinders binary reproducibility as the output will change if the build system configuration changes.
I guess this warning message is because we use some relevant env. So I check openembedded-core/bitbake/conf/bitbake.conf file
- TMPDIR = "${TOPDIR}/tmp" -> WORKDIR = "${TMPDIR}/work/${PF}" -> …
I think if we use relevant env that will get this warning message.
and I think we can use this method avoid this issue e.g.
SRC_URI = "file://example.c"
...
FILES_${PN} += "${bindir}/example"
...
# Remove the TMPDIR reference from the output binary
do_install_append() {
sed -i -e "s|${TMPDIR}|/tmp|g" ${D}${bindir}/example
}
Does anyone have a better solution? Or is my deduction wrong?
run strings <your-binary> this will show if it has strings using build time paths. There are many ways it can get it. Unless we see full source of what you are compiling and how you are compiling its not easy to say.
I still have a lot of buildpaths QA issues in the big builds I'm using, but recently I've noticed also buildpaths QA issue in oe-core recipe which shouldn't have these anymore (as AB would catch that).
WARNING: python3-bcrypt-4.0.1-r0 do_package_qa: QA Issue: File /usr/lib/python3.11/site-packages/bcrypt/_bcrypt.abi3.so in package python3-bcrypt contains reference to TMPDIR [buildpaths]
WARNING: python3-cryptography-39.0.2-r0 do_package_qa: QA Issue: File /usr/lib/python3.11/site-packages/cryptography/hazmat/bindings/_rust.abi3.so in package python3-cryptography contains reference to TMPDIR [buildpaths]
It turned out, it's caused by ld-is-gold in DISTRO_FEATURES and gold linker generates the library path in .gnu.version_d section which seems to be missing completely when default bfd is used:
39.0.2-r0/packages-split $ objdump -x ./python3-cryptography/usr/lib/python3.11/site-packages/cryptography/hazmat/bindings/_rust.abi3.so | grep oe-core -B 1
Version definitions:
1 0x01 0x085b923f /OE/build/oe-core/tmp-glibc/work/core2-64-oe-linux/python3-cryptography/39.0.2-r0/build/target/x86_64-oe-linux-gnu/release/deps/libcryptography_rust.so
I'm not recommending to use gold, we have it mostly from historic reasons until I finish switch to lld or mold. Just wanted to mention it here in case you're using it as well or @kraj having some ideas how to teach gold not to do that (I haven't looked properly yet).
@shr-project I would be happy to help if you have this issue with lld since thats what I am also using with yoe distro and in newer setups. Most of advantages of gold has folded into BFD ld over time, so at this point, its not very appealing for me to fix it, I would rather go to BFD linker and avoid all these troubles.
its not very appealing for me to fix it
Understood, same here :). I was mentioning gold just so you're aware of this side-effect with buildpaths and in case you know some magic flag off the top of your head.
I would rather go to BFD linker and avoid all these troubles.
Yeah if I'm not ready to switch to lld before we're ready to upgrade to next LTS release I'll consider switching back to BFD.
I don't have any issue with lld, other than lack of time to do the switch and test it.
@shr-project can you post the linker command which is building _rust.abi3.so ?
rustc --crate-name bcrypt_rust --edition=2018 src/lib.rs --error-format=json --json=diagnostic-rendered-ansi,artifacts,future-incompat --crate-type cdylib --emit=dep-info,link -C opt-level=3 -C lto=thin --crate-type cdylib -C overflow-checks=on --cfg 'feature="default"' --cfg 'feature="extension-module"' -C metadata=b4d50ebeb43897d3 --out-dir /OE/build/oe-core/tmp-glibc/work/core2-64-oe-linux/python3-bcrypt/4.0.1-r0/build/target/x86_64-oe-linux-gnu/release/deps --target x86_64-oe-linux-gnu -C linker=/OE/build/oe-core/tmp-glibc/work/core2-64-oe-linux/python3-bcrypt/4.0.1-r0/wrapper/target-rust-ccld -L dependency=/OE/build/oe-core/tmp-glibc/work/core2-64-oe-linux/python3-bcrypt/4.0.1-r0/build/target/x86_64-oe-linux-gnu/release/deps -L dependency=/OE/build/oe-core/tmp-glibc/work/core2-64-oe-linux/python3-bcrypt/4.0.1-r0/build/target/release/deps --extern base64=/OE/build/oe-core/tmp-glibc/work/core2-64-oe-linux/python3-bcrypt/4.0.1-r0/build/target/x86_64-oe-linux-gnu/release/deps/libbase64-83b6146f1c9775c8.rlib --extern bcrypt=/OE/build/oe-core/tmp-glibc/work/core2-64-oe-linux/python3-bcrypt/4.0.1-r0/build/target/x86_64-oe-linux-gnu/release/deps/libbcrypt-578f926ec31ff33a.rlib --extern bcrypt_pbkdf=/OE/build/oe-core/tmp-glibc/work/core2-64-oe-linux/python3-bcrypt/4.0.1-r0/build/target/x86_64-oe-linux-gnu/release/deps/libbcrypt_pbkdf-f161b9ede099d2fe.rlib --extern pyo3=/OE/build/oe-core/tmp-glibc/work/core2-64-oe-linux/python3-bcrypt/4.0.1-r0/build/target/x86_64-oe-linux-gnu/release/deps/libpyo3-5d0b6b43dcb7f62a.rlib -L /OE/build/oe-core/tmp-glibc/work/core2-64-oe-linux/python3-bcrypt/4.0.1-r0/recipe-sysroot/usr/lib/rustlib/x86_64-oe-linux-gnu/lib --remap-path-prefix=/OE/build/oe-core/tmp-glibc/work/core2-64-oe-linux/python3-bcrypt/4.0.1-r0=/usr/src/debug/python3-bcrypt/4.0.1-r0
python3-bcrypt/4.0.1-r0/bcrypt-4.0.1/src/_bcrypt $ cat /OE/build/oe-core/tmp-glibc/work/core2-64-oe-linux/python3-bcrypt/4.0.1-r0/wrapper/target-rust-ccld
#!/usr/bin/env python3
import os, sys
orig_binary = "x86_64-oe-linux-gcc -m64 -march=core2 -mtune=core2 -msse3 -mfpmath=sse -fstack-protector-strong -O2 -D_FORTIFY_SOURCE=2 -Wformat -Wformat-security -Werror=format-security --sysroot=/OE/build/oe-core/tmp-glibc/work/core2-6
4-oe-linux/python3-bcrypt/4.0.1-r0/recipe-sysroot -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed -fmacro-prefix-map=/OE/build/oe-core/tmp-glibc/work/core2-64-oe-linux/python3-bcrypt/4.0.1-r0/bcrypt-4.0.1=/usr/src/debug/python3-bcrypt/4.0.1-
r0 -fdebug-prefix-map=/OE/build/oe-core/tmp-glibc/work/core2-64-oe-linux/python3-bcrypt/4.0.1-r0/bcrypt-4.0.1=/usr/src/debug/python3-bcrypt/4.0.1-r0 -fmacro-prefix-map=/OE/build/oe-core/tmp-glibc/work/core2-64-oe-linux/python3-bcrypt/4.
0.1-r0/build=/usr/src/debug/python3-bcrypt/4.0.1-r0 -fdebug-prefix-map=/OE/build/oe-core/tmp-glibc/work/core2-64-oe-linux/python3-bcrypt/4.0.1-r0/build=/usr/src/debug/python3-bcrypt/4.0.1-r0 -fdebug-prefix-map=/OE/build/oe-core/tmp-glib
c/work/core2-64-oe-linux/python3-bcrypt/4.0.1-r0/recipe-sysroot= -fmacro-prefix-map=/OE/build/oe-core/tmp-glibc/work/core2-64-oe-linux/python3-bcrypt/4.0.1-r0/recipe-sysroot= -fdebug-prefix-map=/OE/build/oe-core/tmp-glibc/work/core2-64-
oe-linux/python3-bcrypt/4.0.1-r0/recipe-sysroot-native= -Wl,-z,relro,-z,now"
extras = ""
# Apply a required subset of CC crate compiler flags
# when we build a target recipe for a non-bare-metal target.
# https://github.com/rust-lang/cc-rs/blob/main/src/lib.rs#L1614
if "CRATE_CC_NO_DEFAULTS" in os.environ.keys() and "TARGET" in os.environ.keys() and not "-none-" in os.environ["TARGET"]:
orig_binary += ""
binary = orig_binary.split()[0]
args = orig_binary.split() + sys.argv[1:]
if extras:
args.append(extras)
os.execvp(binary, args)
If I just add -fuse-ld=bfd in wrapper/target-rust-ccld then the path disappears with whole .gnu.version_d····VERDEF section, will upload diffoscope output somewhere if it helps.
I have been seeing loads of these TMPDIR warning on Langdale and now on mickedore. I can send a full listing to the oe mailing list with a call for help. It would be nice if they got cleaned up before the next LTS and before RP decide to turn those warnings into errors.