2

When I compiled Chrome V8 under ubuntu 12.04, I encountered a problem that is

arm-linux-androideabi-g++:fatal error, -fuse-linker-plugin, but liblto_plugin.so not found

The ndk version is r8b. How can I solve this problem?

SamB
  • 9,039
  • 5
  • 49
  • 56
user2862812
  • 21
  • 1
  • 3

2 Answers2

3

When you extra the android-ndk-*.tar.bz2, it should create a symlink named liblto_plugin.soto the real file liblto_plugin.so.?.?.?.

If you have a problem creating symlinks (e.g. a shared directory in a virtual machine), the symlink won't be created and the problem will occur. Try re-extracting the .tar.bz2 file to a filesystem that supports symlinks and verify that liblto_plugin.so exists.

SamB
  • 9,039
  • 5
  • 49
  • 56
eranb
  • 89
  • 8
  • that makes no sense. what does it mean to "parse the...". why the heck would you parse it? if you mean inflate/extract, then how does inflating create a link to the real liblto? how does it know where the real liblto is? – thang Dec 17 '13 at 14:56
  • @thang: Presumably the "parse the" part is an ESL (english as a second language) issue. As for how it knows where the real liblto_plugin.so is, that's presumably because the real liblto_plugin.so comes from the very same tarball (and it's a relative symlink). – SamB Jan 10 '14 at 21:43
1

I found that there were a number of liblto_plugin.so.0.0.0 files in my android source tree and that copying the one in <source_folder>/android/prebuilts/gcc/linux-x86/arm/arm-linux-androideabi-4.7/libexec/gcc/arm-linux-androideabi/4.7/liblto_plugin.so.0.0.0 to liblto_plugin.so in the same location fixed the problem.

I suspect maybe the original was a link to the .0.0.0 version but didn't survive the zip or rsync process I used to copy the source tree to my machine.

SamB
  • 9,039
  • 5
  • 49
  • 56
lane
  • 633
  • 12
  • 18