[llvm-dev] Ubuntu LLVM packages incompatible with clang built projects?

[Tom Stellard via llvm-dev]

On 09/29/2018 01:09 AM, Hans Wennborg via llvm-dev wrote:
> Trunk still has the different gcc and clang versions.
> 
> What's worse, the 7.0.0 release has them too :-( I completely missed
> this and we can't fix it for 7.0.1 since that would also be an ABI
> break.
> 
Is this something we could fix by adding a symbol alias to the
linker script for libLLVM.so?

-Tom

> Alastair, if you noticed this during the release testing, did you
> surface it anywhere?
> 
> 
> On Fri, Sep 28, 2018 at 6:07 PM, Reid Kleckner <rnk at google.com> wrote:
>> Just be aware that those ifdefs were recommitted and reverted several times,
>> so I'm not sure what the state is.
>>
>> On Fri, Sep 28, 2018 at 8:48 AM Alastair Murray via llvm-dev
>> <llvm-dev at lists.llvm.org> wrote:
>>>
>>> Hi Kern,
>>>
>>> We also had issues with mixing GCC/Clang builds when testing the 7.0
>>> release branch.
>>>
>>> My colleague submitted a patch that fixed the issue for us:
>>> * https://reviews.llvm.org/D50710
>>>
>>> I no longer have a copy of the error we were seeing to see if it was the
>>> same, but the fix is to llvm::OptionalStorage and your error message
>>> involves llvm::Optional.  The patch removes a GCC specific ifdef, and
>>> hopefully fixes the issue that made that necessary in the first place, but
>>> we never really knew how the GCC miscompilation was expressed.
>>>
>>> It would be interesting to know whether this resolves your issue, but
>>> regardless we should give the patch a prod.
>>>
>>> Regards,
>>> Alastair Murray.
>>>
>>>
>>> On 27/09/18 08:46, Kern Handa via llvm-dev wrote:
>>>
>>> Hi folks,
>>>
>>> Not sure if this is the right mailing list target, but I'm trying out the
>>> new LLVM 7.0 packages found at http://apt.llvm.org by porting over an
>>> existing LLVM 6.0 project of ours to the new version. In doing so, I found
>>> that the executable always segfaulted at the same spot with no explanation:
>>>
>>> 0x0000000000fefe33 in
>>> llvm::RegisterTargetMachine<llvm::X86TargetMachine>::Allocator(llvm::Target
>>> const&, llvm::Triple const&, llvm::StringRef, llvm::StringRef,
>>> llvm::TargetOptions const&, llvm::Optional<llvm::R
>>> eloc::Model>, llvm::Optional<llvm::CodeModel::Model>,
>>> llvm::CodeGenOpt::Level, bool) ()
>>>
>>> This happens if I build my project and link it against LLVM 7.0 with
>>> either clang++ 6.1 or clang++ 7.0. This does not happen if I build my
>>> project with g++ 8.
>>>
>>> I have also confirmed that building LLVM 7.0 with clang++ and then using
>>> that private build of the libraries fixes the issue.
>>>
>>> To summarize, it seems that there's an ABI incompatibility introduced
>>> somewhere, which means LLVM 7.0 compiled with gcc can only be used by other
>>> projects also built with gcc. Is this something that's being investigated
>>> and to be resolved as a fix in 7.1? If not, is there any official release
>>> note that's remarking on this incompatibility?
>>>
>>> Thanks,
>>> Kern
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>