[yocto] LLVM/CLang only works in Multilib x64

[Yu, Chan KitX]

Hi all,

As some of you might know through IRC and the mailing list itself, I'm trying to get LLVM/CLang to work in Yocto in platforms other than x64 multilib. To set the purpose of this email clear, I am only trying to get LLVM to work as host-only compiler. As much as I want to get LLVM cross compiler working, I will sideline that task for now :(.

After some time of meddling, I finally got LLVM to work in multilib x64 Yocto setup. However, LLVM doesn't really work if I compile Yocto to run on any platform other than x64 multilib. Not even x64 non multilib works. The CLang compiler works and compiles my hello world C code like a charm; however, I could not execute the resulting binary file. ./a.out will return "./a.out: No such file or directory" error and I'm pretty sure a.out exists. Surprisingly, the binary runs on my build machine which is 64 bit Ubuntu machine with multilib setup. I suspect that the binary could run in any x64 machine that has multilib setup. Here I attach the output of readelf -h of binary generated by both CLang and GCC. Both binaries were compiled from the same source code. llvm is binary generated by the CLang compiler and gcc is binary generated by the GCC compiler.

root at valleyisland-64:~# readelf -h llvm
ELF Header:
  Magic:   7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00
  Class:                             ELF64
  Data:                              2's complement, little endian
  Version:                           1 (current)
  OS/ABI:                            UNIX - System V
  ABI Version:                       0
  Type:                              EXEC (Executable file)
  Machine:                           Advanced Micro Devices X86-64
  Version:                           0x1
  Entry point address:               0x4003a0
  Start of program headers:          64 (bytes into file)
  Start of section headers:          5888 (bytes into file)
  Flags:                             0x0
  Size of this header:               64 (bytes)
  Size of program headers:           56 (bytes)
  Number of program headers:         8
  Size of section headers:           64 (bytes)
  Number of section headers:         36
  Section header string table index: 33
root at valleyisland-64:~# readelf -h gcc
ELF Header:
  Magic:   7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00
  Class:                             ELF64
  Data:                              2's complement, little endian
  Version:                           1 (current)
  OS/ABI:                            UNIX - System V
  ABI Version:                       0
  Type:                              EXEC (Executable file)
  Machine:                           Advanced Micro Devices X86-64
  Version:                           0x1
  Entry point address:               0x4003d0
  Start of program headers:          64 (bytes into file)
  Start of section headers:          5864 (bytes into file)
  Flags:                             0x0
  Size of this header:               64 (bytes)
  Size of program headers:           56 (bytes)
  Number of program headers:         8
  Size of section headers:           64 (bytes)
  Number of section headers:         37
  Section header string table index: 34
root at valleyisland-64:~#


Here's the ldd output of the binary from the CLang compiler (I did this from a multilib setup since I couldn't do it from the host):

root at valleyisland-64 # ldd ~/a.out
        linux-vdso.so.1 (0x00007fffe5dea000)
        libc.so.6 => /lib64/libc.so.6 (0x0000003385c00000)
        /lib64/ld-linux-x86-64.so.2 (0x0000003385400000)


I feel that the fact that it links to /lib64 might be the actual reason why I can't run the binary. I couldn't however, find the reason why it links to /lib64 and the solution to this issue.The thing that stumbles me is it only works with multilib but not others. I tried hard to find the reason behind that but it seemed like it is out of my expertise.

I have also attached my LLVM build recipe at http://pastebin.com/Q6svTaj7  . It would be my pleasure to provide more information and logs if you need me to.

Thanks,
Chan Kit
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20150303/e7869bab/attachment.html>