clang-tblgen no such file or directory?

[MastaG]

Hi I'm using your meta-clang bsp-layer in my project and set the following in order to enable it by default:

TOOLCHAIN ?= "clang" TARGET_CXXFLAGS_append_toolchain-clang = " --stdlib=libc++" TUNE_CCARGS_append_toolchain-clang = " --rtlib=compiler-rt --stdlib=libc++"

I'm using latest rev of master branches of bitbake, meta-openembedded, openembedded-core etc.

Build Configuration: BB_VERSION = "1.40.0" BUILD_SYS = "x86_64-linux" NATIVELSBSTRING = "fedora-29" TARGET_SYS = "arm-oe-linux-gnueabi" MACHINE = "odroid-xu3" DISTRO = "odroid-os" DISTRO_VERSION = "release" TUNE_FEATURES = "arm vfp cortexa15 neon vfpv4 thumb callconvention-hard" TARGET_FPU = "hard" meta-clang = "master:a78fabe9c3b6e07edee092e6f02e9bd9690a70e5" meta-oe meta-filesystems meta-multimedia meta-networking meta-python meta-webserver meta-perl meta-initramfs = "master:08cc1df81cff36fff160dbca27880c3740d3ed3e" meta = "master:e37a1ecc292b684daa49f2da2e19e0aa975f0959" meta-rust = "master:f2f17c58b00d12e795fc9c5f66c1bb82759bf72f" odroid-os = "master:6a7bc767f8d9b1070d3da0a2e1c4dfb0ea1f1baa" meta-odroid = "master:3a4b1753852b2e8559b7b293f58e698b1468fca9" meta-browser = "master:41d3e6baea266a652c2d4dbdeca767a3054e13e8" meta-local = "master:6a7bc767f8d9b1070d3da0a2e1c4dfb0ea1f1baa" meta-qt5 = "master:fb71293f257c6fd02ccc06765a96dbf11d4569a0"

But clang-native seems to fail with: FAILED: tools/clang/include/clang/Basic/DiagnosticCommonKinds.inc cd /media/data/home/mastag/odroid-oe-core/build/tmp/work/x86_64-linux/clang-native/8.0.0-r0/build/tools/clang/stage2-bins && /media/data/home/mastag/odroid-oe-core/build/tmp/work/x86_64-linux/clang-native/8.0.0-r0/build/tools/clang/stage2-bins/NATIVE/bin/clang-tblgen -gen-clang-diags-defs -clang-component=Common -I /media/data/home/mastag/odroid-oe-core/build/tmp/work-shared/llvm-project-source-8.0.0-r0/git/clang/include/clang/Basic -I /media/data/home/mastag/odroid-oe-core/build/tmp/work-shared/llvm-project-source-8.0.0-r0/git/llvm/include /media/data/home/mastag/odroid-oe-core/build/tmp/work-shared/llvm-project-source-8.0.0-r0/git/clang/include/clang/Basic/Diagnostic.td -o tools/clang/include/clang/Basic/DiagnosticCommonKinds.inc -d tools/clang/include/clang/Basic/DiagnosticCommonKinds.inc.d /bin/sh: /media/data/home/mastag/odroid-oe-core/build/tmp/work/x86_64-linux/clang-native/8.0.0-r0/build/tools/clang/stage2-bins/NATIVE/bin/clang-tblgen: No such file or directory

clang-native.do_compile.zip

See the attched log file.

Now the strange thing is that the executable does seem to exist:

/media/data/home/mastag/odroid-oe-core/build/tmp/work/x86_64-linux/clang-native/8.0.0-r0/build/tools/clang/stage2-bins/NATIVE/bin/clang-tblgen: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, not stripped

ldd /media/data/home/mastag/odroid-oe-core/build/tmp/work/x86_64-linux/clang-native/8.0.0-r0/build/tools/clang/stage2-bins/NATIVE/bin/clang-tblgen linux-vdso.so.1 (0x00007fff68f79000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fee33c50000) libz.so.1 => /media/data/home/mastag/odroid-oe-core/build/tmp/work/x86_64-linux/clang-native/8.0.0-r0/recipe-sysroot-native/usr/lib/libz.so.1 (0x00007fee33c36000) librt.so.1 => /lib64/librt.so.1 (0x00007fee33c2c000) libdl.so.2 => /lib64/libdl.so.2 (0x00007fee33c26000) libtinfo.so.5 => /media/data/home/mastag/odroid-oe-core/build/tmp/work/x86_64-linux/clang-native/8.0.0-r0/recipe-sysroot-native/usr/lib/libtinfo.so.5 (0x00007fee33bfa000) libm.so.6 => /lib64/libm.so.6 (0x00007fee33a74000) libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007fee338dc000) libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007fee338c1000) libc.so.6 => /lib64/libc.so.6 (0x00007fee336fb000) /lib/ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2 (0x00007fee33c93000)

And when I run it.. it does say: No such file or directory??

strace -s 300 -f /media/data/home/mastag/odroid-oe-core/build/tmp/work/x86_64-linux/clang-native/8.0.0-r0/build/tools/clang/stage2-bins/NATIVE/bin/llvm-tblgen execve("/media/data/home/mastag/odroid-oe-core/build/tmp/work/x86_64-linux/clang-native/8.0.0-r0/build/tools/clang/stage2-bins/NATIVE/bin/llvm-tblgen", ["/media/data/home/mastag/odroid-oe-core/build/tmp/work/x86_64-linux/clang-native/8.0.0-r0/build/tools/clang/stage2-bins/NATIVE/bin/llvm-tblgen"], 0x7ffc545e3de8 / 27 vars /) = -1 ENOENT (No such file or directory) strace: exec: No such file or directory +++ exited with 1 +++

Any ideas on this one?

[kraj]

you do not need to set

TARGET_CXXFLAGS_append_toolchain-clang = " --stdlib=libc++"
TUNE_CCARGS_append_toolchain-clang = " --rtlib=compiler-rt --stdlib=libc++"

anymore its already default when TOOLCHAIN = "clang"

The build issue seems quite unique to me, usually this error means it did not find right ldso to execute it. So you might want to launch it using right ldso from /lib or /lib64 whereever it is on your host distro. If that does not run either then I would think it did not build it correctly, maybe a build race of some sort. You might want to do a clean build from latest meta-clang and see if that helps

[MastaG]

Alright, so I only set: TOOLCHAIN = "clang" Furthermore, I've updated my host OS (Fedora 29 x86_64) and all meta bsp-layers again. I've removed some distro features such as: ld-is-gold

And started fresh again.. but still some binaries do not run: -bash: /media/data/home/mastag/odroid-oe-core/build/tmp/work/x86_64-linux/clang-native/8.0.0-r0/build/tools/clang/stage2-bins/NATIVE/bin/llvm-config: No such file or directory

Some do run, like: /media/data/home/mastag/odroid-oe-core/build/tmp/work/x86_64-linux/clang-native/8.0.0-r0/build/tools/clang/stage2-bins/NATIVE/bin/llvm-lit usage: llvm-lit [-h] [--version] [-j N] [--config-prefix NAME] [-D NAME=VAL] [-q] [-s] [-v] [-vv] [-a] [-o PATH] [--no-progress-bar] [--show-unsupported] [--show-xfail] [--path PATH] [--vg] [--vg-leak] [--vg-arg ARG] [--time-tests] [--no-execute] [--xunit-xml-output XUNIT_OUTPUT_FILE] [--timeout MAXINDIVIDUALTESTTIME] [--max-failures MAXFAILURES] [--max-tests N] [--max-time N] [--shuffle] [-i] [--filter REGEX] [--num-shards M] [--run-shard N] [--debug] [--show-suites] [--show-tests] [--single-process] [test_paths [test_paths ...]] llvm-lit: error: No inputs specified

Here's my basic configuration: https://github.com/MastaG/odroid-oe-core/blob/master/odroid-os/conf/distro/odroid-os-common.conf

Perhpas I'm missing some distro features? Or do I need to install some packages on my host OS to satisfy these binaries?

Could you give me more information regarding the ldso I should be using?

[kraj]

Can you upload the bad binary somewhere ? I would like to look into it and see if I can see something that can give some clue.

I use archlinux and ubuntu 18.04 and it builds without issues for me for all arches I try. I use Yoe Distro

https://github.com/YoeDistro/yoe-distro

[MastaG]

Of course my friend: https://www.mastag.nl/llvm.tar.gz

Reason that llvm-lit works and the others don't is because the llvm-lit is a python script. The other ones are ELF-files and do not run for some reason.

Did you install llvm/c-lang or other packages on your host OS ?

[kraj]

yes I have clang installed on my host. your binaries work perfectly fine on my archlinux host here

% ln -s /usr/lib/libtinfo.so.6 libtinfo.so.5
[kraj@apollo ~/x/bin]
% ls -l
total 4.4M
-rwxr-xr-x 1 kraj users 1.2M Mar  6 07:42 clang-tblgen*
lrwxrwxrwx 1 kraj users   22 Mar  7 06:33 libtinfo.so.5 -> /usr/lib/libtinfo.so.6*
-rwxr-xr-x 1 kraj users 210K Mar  6 07:41 llvm-config*
-rwxr-xr-x 1 kraj users 2.5K Mar  6 07:37 llvm-lit*
-rwxr-xr-x 1 kraj users 3.0M Mar  6 07:41 llvm-tblgen*
[kraj@apollo ~/x/bin]
% ./clang-tblgen
./clang-tblgen: error while loading shared libraries: libtinfo.so.5: cannot open shared object file: No such file or directory
[kraj@apollo ~/x/bin]
% LD_LIBRARY_PATH=. ./clang-tblgen
^C
[kraj@apollo ~/x/bin]
% LD_LIBRARY_PATH=. ./llvm-lit
usage: llvm-lit [-h] [--version] [-j N] [--config-prefix NAME] [-D NAME=VAL]
                [-q] [-s] [-v] [-vv] [-a] [-o PATH] [--no-progress-bar]
                [--show-unsupported] [--show-xfail] [--path PATH] [--vg]
                [--vg-leak] [--vg-arg ARG] [--time-tests] [--no-execute]
                [--xunit-xml-output XUNIT_OUTPUT_FILE]
                [--timeout MAXINDIVIDUALTESTTIME] [--max-failures MAXFAILURES]
                [--max-tests N] [--max-time N] [--shuffle] [-i]
                [--filter REGEX] [--num-shards M] [--run-shard N] [--debug]
                [--show-suites] [--show-tests] [--single-process]
                [test_paths [test_paths ...]]
llvm-lit: error: No inputs specified
[kraj@apollo ~/x/bin]
% LD_LIBRARY_PATH=. ./llvm-config
usage: llvm-config <OPTION>... [<COMPONENT>...]

Get various configuration information needed to compile programs which use
LLVM.  Typically called from 'configure' scripts.  Examples:
  llvm-config --cxxflags
  llvm-config --ldflags
  llvm-config --libs engine bcreader scalaropts

Options:
  --version         Print LLVM version.
  --prefix          Print the installation prefix.
  --src-root        Print the source root LLVM was built from.
  --obj-root        Print the object root used to build LLVM.
  --bindir          Directory containing LLVM executables.
  --includedir      Directory containing LLVM headers.
  --libdir          Directory containing LLVM libraries.
  --cmakedir        Directory containing LLVM cmake modules.
  --cppflags        C preprocessor flags for files that include LLVM headers.
  --cflags          C compiler flags for files that include LLVM headers.
  --cxxflags        C++ compiler flags for files that include LLVM headers.
  --ldflags         Print Linker flags.
  --system-libs     System Libraries needed to link against LLVM components.
  --libs            Libraries needed to link against LLVM components.
  --libnames        Bare library names for in-tree builds.
  --libfiles        Fully qualified library filenames for makefile depends.
  --components      List of all possible components.
  --targets-built   List of all targets currently built.
  --host-target     Target triple used to configure LLVM.
  --build-mode      Print build mode of LLVM tree (e.g. Debug or Release).
  --assertion-mode  Print assertion mode of LLVM tree (ON or OFF).
  --build-system    Print the build system used to build LLVM (always cmake).
  --has-rtti        Print whether or not LLVM was built with rtti (YES or NO).
  --has-global-isel Print whether or not LLVM was built with global-isel support (ON or OFF).
  --shared-mode     Print how the provided components can be collectively linked (`shared` or `static`).
  --link-shared     Link the components as shared libraries.
  --link-static     Link the component libraries statically.
  --ignore-libllvm  Ignore libLLVM and link component libraries instead.
Typical components:
  all               All LLVM libraries (default).
  engine            Either a native JIT or a bitcode interpreter.

[MastaG]

well... that's the strangest thing I ever came across..

ldd llvm-tblgen linux-vdso.so.1 (0x00007ffccfbaf000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f635834a000) libz.so.1 => /media/data/home/mastag/odroid-oe-core/build/tmp/work/x86_64-linux/clang-native/8.0.0-r0/recipe-sysroot-native/usr/lib/libz.so.1 (0x00007f6358330000) librt.so.1 => /lib64/librt.so.1 (0x00007f6358326000) libdl.so.2 => /lib64/libdl.so.2 (0x00007f6358320000) libtinfo.so.5 => /media/data/home/mastag/odroid-oe-core/build/tmp/work/x86_64-linux/clang-native/8.0.0-r0/recipe-sysroot-native/usr/lib/libtinfo.so.5 (0x00007f63582f4000) libm.so.6 => /lib64/libm.so.6 (0x00007f635816e000) libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007f6357fd6000) libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f6357fbb000) libc.so.6 => /lib64/libc.so.6 (0x00007f6357df5000) /lib/ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2 (0x00007f635838a000)

LD_LIBRARY_PATH=/usr/lib64 ldd ./llvm-tblgen linux-vdso.so.1 (0x00007fffd0d50000) libpthread.so.0 => /usr/lib64/libpthread.so.0 (0x00007f38daadf000) libz.so.1 => /usr/lib64/libz.so.1 (0x00007f38daac5000) librt.so.1 => /usr/lib64/librt.so.1 (0x00007f38daabb000) libdl.so.2 => /usr/lib64/libdl.so.2 (0x00007f38daab5000) libtinfo.so.5 => /usr/lib64/libtinfo.so.5 (0x00007f38daa88000) libm.so.6 => /usr/lib64/libm.so.6 (0x00007f38da902000) libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00007f38da76a000) libgcc_s.so.1 => /usr/lib64/libgcc_s.so.1 (0x00007f38da74f000) libc.so.6 => /usr/lib64/libc.so.6 (0x00007f38da589000) /lib/ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2 (0x00007f38dab03000)

When I run with LD_LIBRARY_PATH set to /usr/lib64, it'll use my systems libz and libtinfo. Still I get the same error:

LD_LIBRARY_PATH=/usr/lib64 strace -s 300 ./llvm-tblgen execve("./llvm-tblgen", ["./llvm-tblgen"], 0x7ffc6c274b60 / 27 vars /) = -1 ENOENT (No such file or directory) strace: exec: No such file or directory +++ exited with 1 +++

It happens on both my Fedora 29 laptop and my build server.

I wish I could find out what's causing this... e.g. perhaps it misses something on my host?

[kraj]

I do not have fedora host handy, but you could try building it in a virtualbox running ubuntu 18.04 which is freshly installed, just so you can take out the host factor. Since the binraries are running ok, I think its something to do with host.

[MastaG]

yeah I think so as well. Thanks for helping out my friend :) I'll continue to investigate this on my own and close the issue for now.

[kraj]

No problem, Please keep me posted if you find whats the solution, or need help.

[RichardSun1116]

I encountered the same problem as MastaG mentioned, and I tried to created a symbolic link under /lib/ to workaround it. here are my steps: $ cd /lib $ ln -nfs /lib64/ld-linux-x86-64.so.2 ld-linux-x86-64.so.2 after this work , the llvm-tblgen can run successfully and clang could be generated. My environment is the same as kraj's "ubuntu 18.04", but I compiled the arm(32-bits) project. I think it may a problem to set the llvm-tblgen's requesting program interpreter as /lib/ld-linux-x86-64.so.2. Is the correct path /lib64/ld-linux-x86-64.so.2 even compiling arm cross compiler ?

[MastaG]

I was building for 32bit arm as well :) I'm going to try it right away!

Op wo 13 mrt. 2019 09:55 schreef RichardSun1116 notifications@github.com:

I encountered the same problem as MastaG mentioned, and I tried to created a symbolic link under /lib/ to workaround it. here are my steps: $ cd /lib $ ln -nfs /lib64/ld-linux-x86-64.so.2 ld-linux-x86-64.so.2 after this work , the llvm-tblgen can run successfully and clang could be generated. My environment is the same as kraj's "ubuntu 18.04", but I compiled the arm(32-bits) project. I think it may a problem to set the llvm-tblgen's requesting program interpreter as /lib/ld-linux-x86-64.so.2. Is the correct path /lib64/ld-linux-x86-64.so.2 even compiling arm cross compiler ?

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/kraj/meta-clang/issues/106#issuecomment-472333968, or mute the thread https://github.com/notifications/unsubscribe-auth/AOURExIBSsUoxa62LifiNBoQiz9f-Y6fks5vWLz_gaJpZM4beg7v .

[MastaG]

Yeahh!!!! Having the ld-linux-x86-64.so.2 symlinked to /lib makes the binaries run for me :+1: @kraj What could be the cause for this? because ldd does show this: /lib/ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2 (0x00007f635838a000)

It seems /lib/ld-linux-x86-64.so.2 has to exist for the binary to run... Meaning that the linker used to build these binaries probably have some hardcoded value for /lib due to building for 32bit arm?

[kraj]

My daily driver is a archlinux box where I have

% ls -l /lib64
lrwxrwxrwx 1 root root 7 Dec  6 06:19 /lib64 -> usr/lib/

% ls -l /lib
lrwxrwxrwx 1 root root 7 Dec  6 06:19 /lib -> usr/lib/

and have never seen this issue, but It might be worth to debug into it, OTOH I don't know whats going on, but I will try to figure out, tlbgen might be making crude assumptions.

[mrchapp]

This is a "me too" post. In our case, we have been using meta-clang just fine on Morty, Rocko and Sumo; Thud and master, however, fail with this problem. The host I tried this on was:

$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 18.04.2 LTS
Release:    18.04
Codename:   bionic

As for lib:

$ ls -ld /lib*/ld-linux* /lib*
drwxr-xr-x 21 root root 40 Dec  1 11:31 /lib
drwxr-xr-x  2 root root 49 Jun 28  2018 /lib32
lrwxrwxrwx  1 root root 10 Apr 16  2018 /lib32/ld-linux.so.2 -> ld-2.27.so
drwxr-xr-x  2 root root  3 Apr 27  2018 /lib64
lrwxrwxrwx  1 root root 32 Apr 16  2018 /lib64/ld-linux-x86-64.so.2 -> /lib/x86_64-linux-gnu/ld-2.27.so
lrwxrwxrwx  1 root root 20 Apr 16  2018 /lib/ld-linux.so.2 -> /lib32/ld-linux.so.2
drwxr-xr-x  2 root root 47 May 24  2018 /libx32
lrwxrwxrwx  1 root root 10 Apr 16  2018 /libx32/ld-linux-x32.so.2 -> ld-2.27.so

[edtanous]

Seeing the same issue on a 32 bit arm yocto machine target, Ubuntu 18.04 build machine. Identical build machine details as @mrchapp.

➜  meta-clang git:(master) ✗ ls -ld /lib*/ld-linux* /lib*
drwxr-xr-x 23 root root 4096 Oct  5 14:47 /lib
drwxr-xr-x  2 root root 4096 Dec 13 15:58 /lib32
lrwxrwxrwx  1 root root   10 Apr 16  2018 /lib32/ld-linux.so.2 -> ld-2.27.so
drwxr-xr-x  2 root root 4096 Jul 24  2018 /lib64
lrwxrwxrwx  1 root root   32 Sep 10  2018 /lib64/ld-linux-x86-64.so.2 -> /lib/x86_64-linux-gnu/ld-2.27.so
lrwxrwxrwx  1 root root   25 Apr 16  2018 /lib/ld-linux.so.2 -> i386-linux-gnu/ld-2.27.so

➜  meta-clang git:(master) ✗ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 18.04.2 LTS
Release:    18.04
Codename:   bionic

The suggestion from @RichardSun1116 does resolve it temporarily, but I would like to see a more permanent fix if it's possible.

[kraj]

@edtanous Noticed, I need to get access to an ubuntu box to see whats going on.. planning to get to one this week

[petegriffin]

I also see this issue, when I switched from gcc to using meta-clang to build Chromium-ozone-wayland v73 (to try and avoid other build errors there with gcc..doh)

[olivierschonken]

I saw this issue while building yocto-warrior with meta-clang master for x86_64 on an x86_64 ubuntu system.

FWIW, Instead of modifying my system, I changed meta-clang/recipes-devtools/clang/clang/0002-clang-driver-Use-lib-for-ldso-on-OE.patch to

break;
   case llvm::Triple::systemz:
@@ -631,7 +631,7 @@ std::string Linux::getDynamicLinker(const ArgList &Args) const {
   case llvm::Triple::x86_64: {
     bool X32 = Triple.getEnvironment() == llvm::Triple::GNUX32;

-    LibDir = X32 ? "libx32" : "lib64";
+    LibDir = X32 ? "lib" : "lib64";
     Loader = X32 ? "ld-linux-x32.so.2" : "ld-linux-x86-64.so.2";
break;

and that fixed the build for me.

[kraj]

@olivierschonken I think you narrowed the problem, thanks. The issue the original patch 0002-clang-driver-Use-lib-for-ldso-on-OE.patch fixes is OE specific especially for cross and target compilers where OE uses lib ( not lib64) for libdirs when multilib is not used and that includes architectures like x86_64 as well, this is departure from other major distributions where default libdir for x86_64 is always lib64 regardless of multilib and clang assumes that.

So if I apply this patch then it makes native compiler work ( on build host like ubuntu) but breaks the cross and target compilers for x86_64 target in OE

So we have to find a smarter way to use this difference. Ideally OE should have defaulted to whatever other distros are doing but thats the legacy its living with, I can try to change that in OE-core but thats quite fundamental battle.

[kraj]

this should be fixed in master now. Please verify and reopen if still an issue