Bug#759538: libclang1-3.4: multiple versions of libclang causing codelite to segfault
Sylvestre Ledru
sylvestre at debian.org
Thu Aug 28 10:22:54 UTC 2014
On 28/08/2014 12:18, James Cowgill wrote:
> On Thu, 28 Aug 2014 12:02:01 +0200 Sylvestre Ledru <sylvestre at debian.org> wrote:
>> On 28/08/2014 11:41, James Cowgill wrote:
>>> Package: libclang1-3.4
>>> Version: 1:3.4.2-8
>>> Severity: important
>>> Control: affects -1 codelite-plugins
>>>
>>> Hi,
>>>
>>> The clang co-installable update is causing crashes is codelite when multiple
>>> versions of libclang1 are installed.
>>>
>>> Normally codelite (with codelite-plugins) will load libclang.so.1 and
>>> liblldb.so.1 from LLVM 3.4 and everything works:
>>> codelite
>>> libclang.so.1 (symlink to libclang-3.4.so.1)
>>> libLLVM-3.4.so.1
>>> LLDBDebugger.so
>>> liblldb.so.1
>>> (libLLVM-3.4.so.1 already loaded)
>>>
>>> But if you install libclang1-3.6 at the same time, codelite will load that
>>> library because libclang1.so.1 now points to it:
>>> codelite
>>> libclang.so.1 (symlink to libclang-3.6.so.1)
>>> libLLVM-3.6.so.1
>>> LLDBDebugger.so
>>> liblldb.so.1
>>> libLLVM-3.4.so.1 (symbol collision)
>>>
>>> Then codelite segfaults in the constructors for libLLVM-3.4 due to (I
>>> assume) a
>>> symbol collision with libLLVM-3.6.so.1
>> Interesting issue.
>>
>> codelite should link against libclang-X.Y instead of libclang. I will remove
>> libclang.so
>> but I agree that there is a problem with lldb.
>
> As long as the SONAME in libclang-X.Y is "libclang.so.1", the runtime
> linker will still try to search for that file anyway (and not
> libclang-X.Y.so.1) so that won't make any difference.
Updating the SONAME was implied
S
More information about the Pkg-llvm-team
mailing list