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@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@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@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@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
-- 
_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Reply via email to