Bug#759538: libclang1-3.4: multiple versions of libclang causing codelite to segfault

Sylvestre Ledru sylvestre at debian.org
Thu Aug 28 10:22:34 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