[patch] Don't use appending linkage for embeded bitcode

[Steven Wu via cfe-commits]

Hi Rafael

Thanks for notice this! That would definitely cause duplicated symbol error and I should definitely change that. 
Here is some background:
ld64 in Xcode 7+ knows how to handle the embedded bitcode correctly but not the ones in earlier Xcode. The old ld64 will simply concatenate the bitcode files which is not the right thing to do. So there is a symbol generated at the place to prevent user to link the bitcode object file with old ld64 because older ld64 will fail and report duplicated symbols.
I have a radar tracking to change the linkage type when upstream but I dropped the ball on that one. The correct thing to do is to make it internal and add to llvm.used. I will come up with a patch.

Steven

> On May 13, 2016, at 9:46 AM, Rafael Espíndola <rafael.espindola at gmail.com> wrote:
> 
> Hi Steven,
> 
> I think there was a mistake when picking this linkage. The appending
> linkage is really just for things that llvm itself special cases. By
> an historical artifact it was codegened just like external.
> 
> The attached patch changes it to external linkage. I tested that the
> produced .o file is bit by bit identical with this change.
> 
> But I have to ask, what is the intended use? I was under the
> impression that the idea was to allow multiple .o files to have their
> IR embedded and have the liker concatenate them.
> 
> Currently, with or without this patch, I expect you to get a
> duplicated symbol error. To implement the above the symbol should be
> internal end the GV added to llvm.used.
> 
> Cheers,
> Rafael
> <t.diff>