tree 38693797caeaec8aafc7bc6c8e78942913507fd9
parent 15eb6af46c973715da1fc6737a67feab627d5dca
author Lai Wei-Chih <Robert.Lai@mediatek.com> 1375106485 +0800
committer Lai Wei-Chih <Robert.Lai@mediatek.com> 1375147211 +0800

Fix le32 linking issue by treating ".bc" as ".o".

This issue occurs only when bitcode filename ends with .bc,
filename ends with ".o" or ".so" doesn't have such problem.

Issue description:

Assume libc.bc is already linked by le32-none-ndk-link, and it
contains the bitcode wrapper we needed.

clang -shared -emit-llvm -target le32-none-ndk a.bc libc.bc -o b.bc

It takes 3 phases to complete the linking,

(1) clang -cc1 a.bc -emit-llvm-bc -target le32-none-ndk -o /tmp/a.bc
(2) clang -cc1 libc.bc -emit-llvm-bc -target le32-none-ndk -o /tmp/libc.bc
(3) le32-none-ndk-link -shared /tmp/a.bc /tmp/libc.bc -o b.bc

In the second phase, /tmp/libc.bc is generated without bitcode wrapper.
This makes the final linking phase incorrectly.

The solution here is treating ".bc" as ".o", then phase 1 and 2 could be skipped.

Change-Id: Ie55b62d95d8787f4fb778247e75e7617347ab8f0