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

[James Cowgill]

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.

Are the different versions of libclang ABI compatible?
If not they should have different SONAMES (like libLLVM...)

James