kraj
commented
5 years ago Can you post the build configuration
Open Lorac opened 5 years ago
kraj
commented
5 years ago Can you post the build configuration
Lorac
commented
5 years ago I'm on a native x86_64 cross compiling for aarch64. Is that the information you were looking for?
kraj
commented
5 years ago Are you able to post the Build Configuration printed by bitbake at the beginning of build
Lorac
commented
5 years ago Build Configuration:
BB_VERSION = "1.40.0"
BUILD_SYS = "x86_64-linux"
NATIVELSBSTRING = "universal"
TARGET_SYS = "aarch64-piko-linux"
MACHINE = "OUR MACHINE"
DISTRO = "piko"
DISTRO_VERSION = "2.6.1"
TUNE_FEATURES = "aarch64"
TARGET_FPU = ""
meta
meta-poky
meta-yocto-bsp = "HEAD:db755e5b6165fa0fdd95bb17d24015278574efdb"
meta-oe
meta-multimedia
meta-python = "HEAD:02ac765fa8095626386fc592f9d65f7e4f53e77b"
meta-xilinx-bsp
meta-xilinx-contrib = "HEAD:d2cccbabeceec246e92132151d71831f50f74bf1"
meta-xilinx-tools = "HEAD:ab9ff94851230027be445faf218b7d7eb1bf81c7"
meta-qt5 = "HEAD:68afc7108388d76ad53200c7f027609820a6ab3a"
meta-clang = "HEAD:686c29d744a5c3b0766e50a137cca777e0c7cfe5"You seem to be using thud release Could you try same with master
nrclark
commented
5 years ago I've got the same bug, also building for an aarch64 target (might not be an aarch-specific thing though). I'm also on thud, since that's the current release (we couldn't wait for warrior, and needed to lock a version).
My SDK errors are very slightly different - they read "interp size = 75 and 106 is needed" , but otherwise the same.
I'm happy to help repro/debug as needed. Is there anything about master that I can backport into our thud layer which might tweak the error? We use the SDK pretty heavily.
Here's my build config with a couple of codenames blanked out:
Build Configuration:
BB_VERSION = "1.40.0"
BUILD_SYS = "x86_64-linux"
NATIVELSBSTRING = "universal"
TARGET_SYS = "aarch64-poky-linux"
MACHINE = $DISTRO_MACHINE"
DISTRO = $DISTRO_NAME
DISTRO_VERSION = "0.9"
TUNE_FEATURES = "aarch64 crypto cortexa53"
TARGET_FPU = ""
meta
meta-poky
meta-yocto-bsp = "HEAD:1cab405d88149fd63322a867c6adb4a80ba68db3"
meta-multimedia
meta-networking
meta-oe
meta-python = "thud:4cd3a39f22a2712bfa8fc657d09fe2c7765a4005"
meta-clang = "master:ae23e30d7050779186c93b2cefd0690ce3023818"
meta-$BSP = "HEAD:433f379c457313f586c8806ee1c4b2384ddb1091"
meta-$PRODUCT = "HEAD:6e8be36bdce9a694bf5fb29c7b0c17a8f08d5f5b"Can you try it on master/warrior please ?
Lorac
commented
5 years ago So I'm still stuck on poky thud, but I tried with meta-clang master and same problem for now...
I won't be able to upgrade poky until meta-xillinx push their update for the warrior release.
Lorac
commented
5 years ago We tried to generate a sdk for a x86-64 machine and getting the same errors.
kraj
commented
5 years ago @Lorac I think the problem comes from OE-core so you need to try poky/oe-core master as well along with meta-clang
Atomisirsi
commented
5 years ago I can confirm this issue with all layers (poky, meta-oe, meta-clang) on latest warrior.
Only difference is, I get the messages with
ERROR: could not relocate .../sdk/qemu/sysroots/x86_64-oesdk-linux/usr/lib/LLVMgold.so, interp size = 78 and 84 is needed.My build configuration is:
Build Configuration:
BB_VERSION = "1.42.0"
BUILD_SYS = "x86_64-linux"
NATIVELSBSTRING = "universal"
TARGET_SYS = "arm-$SUPPLIER-linux-gnueabi"
MACHINE = "qemuarm"
DISTRO = "$DISTRO"
DISTRO_VERSION = "2.7-0"
TUNE_FEATURES = "arm armv7ve vfp thumb neon callconvention-hard"
TARGET_FPU = "hard"
meta
meta-poky
meta-yocto-bsp = "feature/clang:a3b49960885626544e043731eada210266d26bd6"
meta-oe = "warrior:8d5dcd6522e9d15e68637b6d7dda0401f9bb91d0"
meta-ptx = "HEAD:1a5ad62192cd352ac596d52a2281802cbf29d619"
meta-rauc = "warrior:a1a5d590a6548a1ee43e3dbff98fd23af4207339"
meta-clang = "warrior:4babecabc58ec64a5a12c180165996ea34f9e48a"Here are additional infos. The installed files seem to be linked against /usr/local/oecore-x86_64, instead of the real SDK location ../sdk/qemu:
$ file .../sdk/qemu/sysroots/x86_64-oesdk-linux/usr/bin/*clang*
.../sdk/qemu/sysroots/x86_64-oesdk-linux/usr/bin/clang: symbolic link to clang-8
.../sdk/qemu/sysroots/x86_64-oesdk-linux/usr/bin/clang++: symbolic link to clang
.../sdk/qemu/sysroots/x86_64-oesdk-linux/usr/bin/clang-8: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/lib/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, stripped
.../sdk/qemu/sysroots/x86_64-oesdk-linux/usr/bin/clang-apply-replacements: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/lib/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, stripped
.../sdk/qemu/sysroots/x86_64-oesdk-linux/usr/bin/clang-change-namespace: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/lib/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, stripped
.../sdk/qemu/sysroots/x86_64-oesdk-linux/usr/bin/clang-check: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/lib/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, stripped
.../sdk/qemu/sysroots/x86_64-oesdk-linux/usr/bin/clang-cl: symbolic link to clang
.../sdk/qemu/sysroots/x86_64-oesdk-linux/usr/bin/clang-cpp: symbolic link to clang
.../sdk/qemu/sysroots/x86_64-oesdk-linux/usr/bin/clangd: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/lib/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, stripped
.../sdk/qemu/sysroots/x86_64-oesdk-linux/usr/bin/clang-extdef-mapping: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/lib/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, stripped
.../sdk/qemu/sysroots/x86_64-oesdk-linux/usr/bin/clang-format: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/lib/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, stripped
.../sdk/qemu/sysroots/x86_64-oesdk-linux/usr/bin/clang-import-test: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/lib/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, stripped
.../sdk/qemu/sysroots/x86_64-oesdk-linux/usr/bin/clang-include-fixer: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/lib/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, stripped
.../sdk/qemu/sysroots/x86_64-oesdk-linux/usr/bin/clang-offload-bundler: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/lib/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, stripped
.../sdk/qemu/sysroots/x86_64-oesdk-linux/usr/bin/clang-query: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/lib/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, stripped
.../sdk/qemu/sysroots/x86_64-oesdk-linux/usr/bin/clang-refactor: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/lib/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, stripped
.../sdk/qemu/sysroots/x86_64-oesdk-linux/usr/bin/clang-rename: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/lib/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, stripped
.../sdk/qemu/sysroots/x86_64-oesdk-linux/usr/bin/clang-reorder-fields: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/lib/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, stripped
.../sdk/qemu/sysroots/x86_64-oesdk-linux/usr/bin/clang-tblgen: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/lib/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, stripped
.../sdk/qemu/sysroots/x86_64-oesdk-linux/usr/bin/clang-tidy: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/lib/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, stripped
.../sdk/qemu/sysroots/x86_64-oesdk-linux/usr/bin/git-clang-format: Python script, ASCII text executableOK I guess we need to deep dive into it since its seem in many instances. Can you share what is your host OS and version.
Atomisirsi
commented
5 years ago From hostnamectl:
Operating System: Debian GNU/Linux 10 (buster)
Kernel: Linux 4.19.0-5-amd64
Architecture: x86-64@Atomisirsi can you try commenting out the line below
https://github.com/kraj/meta-clang/blob/master/classes/clang.bbclass#L30
kraj
commented
5 years ago Can you try to install this SDK on the SDK host where you see this error
Atomisirsi
commented
5 years ago Thank you very much @kraj: commenting out line 30 fixed the relocating issues.
But the clang tools still do not use the SDK's ld-linux-x86-64.so.2. Instead, they are linked to /lib/ld-linux-x86-64.so.2, which does not exist on Debian 10.
After creating a symlink from the SDK's ld-linux-x86-64.so.2 to /lib/ld-linux-x86-64.so.2, I was finally able to execute the clang tools.
Unfortunatelly, clang seems to lack support for target CPU arm7ve, hence the integration of clang-tidy in our target build environment seems not to be possible.
Though, it's working for target x86-64 where we can just use the system's installation of clang-tidy.
I have tried the SDK you provided and it worked out of the box: No relocation errors and the clang-tools are linked to the SDK's ld-linux-x86-64.so.2.
kraj
commented
5 years ago line 30 fixes that exact problem of nativesdk not using nativesdk ldso. But I think we have nailed the cause of the issue which is good.
kraj
commented
5 years ago This is a hairy problem and especially seen with components compiled with clang targetted for nativesdk, It would need teaching some tricks to clang driver when it comes to creating enough space in ELF header for relocation of toolchain which we do on gcc. Meanwhile a workaround could be to set the paths similar to where it will be installed something like this.
SDK_NAME = "${DISTRO}-${TCLIBC}-${SDKMACHINE}-${IMAGE_BASENAME}-${TUNE_PKGARCH}-${MACHINE}"
SDKPATH = "/opt/${DISTRO}/${SDK_VERSION}"let me know if this workaround works for you and you can live with it for a while.
Atomisirsi
commented
5 years ago The workarounds are acceptable! Now I have a working clang in my SDK for architecture x86_64. Since my last try, I have also included the latest commit on the warrior branch:
commit 16f62e8de7e9816e95f2ba8eeaad7d863bd12c16 (HEAD -> warrior, origin/warrior)
Author: Daniel Dittmann <daniel.dittmann@rohde-schwarz.com>
Date: Thu Aug 1 13:01:47 2019 +0200
use native-clang compiler when building nativesdk-clang
Some cmake based steps when building clang uses BUILD_CC, BUILD_CXX variables,
which points to gcc even if TOOLCHAIN_class-nativesdk = "clang".
This patch sets it to clang if TOOLCHAIN_class-nativesdk = "clang" is set.
Signed-off-by: Daniel Dittmann <daniel.dittmann@rohde-schwarz.com>This could also have had impact, because I use gcc by default and only use clang(-tidy) for static analysis.
kraj
commented
5 years ago @Atomisirsi thanks for report
AKADiNG
commented
4 years ago I've got the same bug, also building for an aarch64 target base on warrior branch,
the error info is:
could not relocate /home/ning.ding/proj/a500-sdk-clang/sysroots/x86_64-bstsdk-linux/usr/bin/clang-offload-bundler, interp size = 72 and 90 is needed. ERROR: could not relocate /home/ning.ding/proj/a500-sdk-clang/sysroots/x86_64-bstsdk-linux/usr/bin/llvm-dwp, interp size = 72 and 90 is needed. ERROR: could not relocate /home/ning.ding/proj/a500-sdk-clang/sysroots/x86_64-bstsdk-linux/usr/bin/obj2yaml, interp size = 72 and 90 is needed. ERROR: could not relocate /home/ning.ding/proj/a500-sdk-clang/sysroots/x86_64-bstsdk-linux/usr/bin/llvm-rc, interp size = 72 and 90 is needed. ERROR: could not relocate /home/ning.ding/proj/a500-sdk-clang/sysroots/x86_64-bstsdk-linux/usr/bin/bugpoint, interp size = 72 and 90 is needed. …………
My build configuration is:
Build Configuration:
BB_VERSION = "1.43.0"
BUILD_SYS = "x86_64-linux"
NATIVELSBSTRING = "ubuntu-18.04"
TARGET_SYS = "aarch64-bst-linux"
MACHINE = "a500"
DISTRO = "bstos"
DISTRO_VERSION = "0.3.3-20191104"
TUNE_FEATURES = "aarch64"
TARGET_FPU = ""
meta = "HEAD:952bfcc3f4b9ee5ba584da0f991f95e80654355a"
meta-clang = "warrior:3611f25304bbb86f4a1600c3399a8a5a6cc050fa"
meta-oe
meta-multimedia
meta-python
meta-networking
meta-filesystems = "HEAD:8d5dcd6522e9d15e68637b6d7dda0401f9bb91d0"
meta-bstos = "a500-luneos-merge:3f47f19ce083183402b5700a8041364747c6e0ef"
meta-qt5 = "master:2a5f9415e48a38f6f4eb0cf375737a2d8438e2fe"
meta-luneos
meta-luneui = "a500-luneos-merge:3f47f19ce083183402b5700a8041364747c6e0ef"
I have tried commenting out line "#TUNE_CCARGS_remove_toolchain-clang_powerpc = "-mhard-float" in clang.bbclass and add
SDK_NAME = "${DISTRO}-${TCLIBC}-${SDKMACHINE}-${IMAGE_BASENAME}-${TUNE_PKGARCH}-${MACHINE}" SDKPATH = "/opt/${DISTRO}/${SDK_VERSION}"
in my bb file, but it does not work.
kraj
commented
4 years ago SDK_NAME = "${DISTRO}-${TCLIBC}-${SDKMACHINE}-${IMAGE_BASENAME}-${TUNE_PKGARCH}-${MACHINE}"
SDKPATH = "/opt/${DISTRO}/${SDK_VERSION}"Should be set in conf/local.conf
AKADiNG
commented
4 years ago SDK_NAME = "${DISTRO}-${TCLIBC}-${SDKMACHINE}-${IMAGE_BASENAME}-${TUNE_PKGARCH}-${MACHINE}" SDKPATH = "/opt/${DISTRO}/${SDK_VERSION}"Should be set in
conf/local.conf
I found that it will be ok when you installed the sdk into the default path,。Chang the install path will call this problem.
kraj
commented
4 years ago yes, as long as your install path is smaller than build path, it will work. The real fix is to create space in ELF header to expand the paths but thats quite invasive and needs a bit of time to get it right and upstream with not accept such a patch.
ghost
commented
4 years ago I wonder why this wasn't an issue in the past? We were using clang 5 for a long time based on this layer and we didn't have any difficulties with the SDK. Maybe this information could point to a possible solution?
kraj
commented
4 years ago A solution would be to do something what we do for binutils/gcc/glibc where it introduces padding section .gccrelocprefix which is then edited by the SDK installer during install to input the final location of SDK. e.g. glibc case
ghost
commented
4 years ago Was this in place before? Why is it that this didn't happen before?
fmhess
commented
4 years ago Can this problem be worked around by simply removing the meta-clang layer? I also removed meta-browser which depended on meta-clang, but I don't think I need that either.
kraj
commented
4 years ago If you don’t need clang then you don’t have this problem
fmhess
commented
4 years ago What I am trying to ask is if Angstrom Zeus needs Clang or if removing the meta-clang layer is going to cause other problems. As far as I know, all Clang is doing for me is generating a bunch of errors when trying to install the SDK.
kraj
commented
4 years ago If you are not building chromium then it’s not must
kraj
commented
4 years ago finally I have tracked it down to a gold linker enhancement that we have now committed to master in yocto/oe-core https://git.openembedded.org/openembedded-core/commit/?id=f856b5f38263251bc48af8ba0da3385c09663d38
I will ask for a backport to dunfell as well. Please test it out if anyone is interested, we can close this bug
ghost
commented
3 years ago finally I have tracked it down to a gold linker enhancement that we have now committed to master in yocto/oe-core https://git.openembedded.org/openembedded-core/commit/?id=f856b5f38263251bc48af8ba0da3385c09663d38
I will ask for a backport to dunfell as well. Please test it out if anyone is interested, we can close this bug
Do you think it would be possible to backport this to zeus as well?
kraj
commented
3 years ago finally I have tracked it down to a gold linker enhancement that we have now committed to master in yocto/oe-core https://git.openembedded.org/openembedded-core/commit/?id=f856b5f38263251bc48af8ba0da3385c09663d38 I will ask for a backport to dunfell as well. Please test it out if anyone is interested, we can close this bug
Do you think it would be possible to backport this to
zeusas well?
this is oe-core we will backport this to dunfell. zeus is already seeing its last release and then it will not receive official updates so it might not see it, but you can always backport to your distro.
ghost
commented
3 years ago Do you think it would be possible to backport this to
zeusas well?this is oe-core we will backport this to dunfell. zeus is already seeing its last release and then it will not receive official updates so it might not see it, but you can always backport to your distro.
This didn't work on zeus, sadly. I'm still seeing the following errors when installing the SDK:
ERROR: could not relocate /work/sdks/SDK-toolchain-os-arm32-rpi3-v0.46-25-g0356e41-linux/sysroots/x86_64-oesdk-linux/usr/lib/libLTO.so.9, interp size = 78 and 134 is needed.
...@fsa-ableton is it possible for you to test the same using master ?
ghost
commented
3 years ago @fsa-ableton is it possible for you to test the same using master ?
Sorry, I cannot get to this right now. I've made a note of this and will get back once I tested it.
vaibhavjadhav377
commented
3 years ago I am also facing the same problem i.e sdk relocating error So I am using zeus openembedded-core and also want to eliminate error using the same. Tune_features for riscv64. Error: It is a long list of error in same format as given below- ERROR: could not relocate /home/vaibhav/oe/openembedded/openembedded-core/newexp/tmp-glibc/deploy/sdk/sdkwithclang/sysroots/x86_64-oesdk-linux/usr/lib/LLVMgold.so, interp size = 78 and 142 is needed.
kraj
commented
3 years ago you need to backport a binutils patch https://git.openembedded.org/openembedded-core/commit/?id=f856b5f38263251bc48af8ba0da3385c09663d38 to zeus openembedded-core
vaibhavjadhav377
commented
3 years ago I backported the binutils patch to zeus openembedded-core. Even though I am facing the same issues i.e relocating and not able to execute clang tools. Following is the patch which I applied. zeusbinutilspatch.txt
kraj
commented
3 years ago I see, do you see this on dunfell or master too ?
vaibhavjadhav377
commented
3 years ago Here I am using riscv sources.
I have checked with dunfell .
But here also I see the same:
ERROR: could not relocate /home/vaibhav/riscv-yocto/build/tmp-glibc/deploy/sdk/clangsdk/sysroots/x86_64-oesdk-linux/usr/lib/libclang-cpp.so.10, interp size = 78 and 130 is needed
Following are the configurations:
Build Configuration:
BB_VERSION = "1.47.0"
BUILD_SYS = "x86_64-linux"
NATIVELSBSTRING = "universal"
TARGET_SYS = "riscv64-oe-linux"
MACHINE = "qemuriscv64"
DISTRO = "nodistro"
DISTRO_VERSION = "nodistro.0"
TUNE_FEATURES = "riscv64"
meta = "work:1824cf062df928de65c1bff5e86e26b7b4d9d784"
meta-oe
meta-python
meta-multimedia
meta-networking = "work:26de7600bdcfbb7c9333b15868f954ca028b81a9"
meta-riscv = "work:e7c5476aedabe3a99a534e920ec6fd278ab06637"
meta-clang = "dunfell:88685736c4a2f27bc72e398c66d5acc4e5628ffa"
kraj
commented
3 years ago @vaibhavjadhav377 can you paste the linker cmdline its using when building libclang-cpp.so.10 in nativesdk-clang
vaibhavjadhav377
commented
3 years ago Following attached file has a linker commandline. libclang-cpp.txt
kraj
commented
3 years ago thanks @vaibhavjadhav377 I see that its specifying -fuse-ld=gold which should have invoked gold linker and provided we have patch for binutils/gold applied to extend the relevant ELF section, it should have worked. Now I wonder,
I will try to reproduce it here and see whats going on. meanwhile if you can run this command alone with --verbose option added, it should show which linker is being called by x86_64-oesdk-linux-clang++
vaibhavjadhav377
commented
3 years ago After executing $./recipe-sysroot-native/usr/bin/x86_64-oesdk-linux/x86_64-oesdk-linux-clang++ --verbose, I get clang version 10.0.1 (https://github.com/llvm/llvm-project ef32c611aa214dea855364efd7ba451ec5ec3f74) Target: x86_64-oesdk-linux Thread model: posix InstalledDir: /home/vaibhav/riscv-yocto/build/tmp-glibc/work/x86_64-nativesdk-oesdk-linux/nativesdk-clang/10.0.1-r0/./recipe-sysroot-native/usr/bin/x86_64-oesdk-linux Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/7 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/7.5.0 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/8 Selected GCC installation: /usr/lib/gcc/x86_64-linux-gnu/7.5.0 Candidate multilib: .;@m64 Candidate multilib: 32;@m32 Candidate multilib: x32;@mx32 Selected multilib: .;@m64
kraj
commented
3 years ago you need to run it with a proper linking step, so it will display the tools involved in whole process.
vaibhavjadhav377
commented
3 years ago when i tried to execute a cpp program using x86_64-oesdk-linux-clang++, it was using following linker "/home/vaibhav/riscv-yocto/build/tmp-glibc/work/x86_64-nativesdk-oesdk-linux/nativesdk-clang/10.0.1-r0/./recipe-sysroot-native/usr/bin/x86_64-oesdk-linux/x86_64-oesdk-linux-ld" For more information I have attached log.txt. log.txt
cah-ableton
commented
3 years ago Hi all, I am testing this patch on zeus and the problem appears to be that the clang tools are built using the build host's toolchain (i.e. /usr/bin/gcc etc.) so the linker in use does not have the large-interp patch. Which toolchain is supposed to be used to build clang? Is there something up with my setup?
kraj
commented
3 years ago @cah-ableton we only need nativesdk-clang in SDK and it should be using the yocto built glibc and binutils to build it. native-clang can use tools from host.
When I setup our SDK I get this error :
The
.....is just to mask the path