Re: [Libcdio-devel] cd-info linking conflict

[plaum]

Hi,

>> Normally, each library should allow installation of different versions
>> in
>> under different prefixes, shouldn't it?
>
>       I think so - BUT something seems to always look in /usr/local/lib
>       first and finds the old version.

It's clear what happens: We compile a new libcdio and
link it with an installed libvcdinfo, which in turn links to an
installed libcdio. The search order doesn't matter here.

> I still don't like versioned symbols - which seem to be the cause
> of the problems in this case

I think the library versioning is useful in this case: It gives at least
a warning that something is wrong. If ld would silently link this,
we would have an executable linked to 2 different versions of libcdio at
the same time (I remember spending several days with gdb in a similar
situation).

The only root of the problem is the circular dependency.

>       The way I've solved similar problems in the past (when version
>       number(s) of libcdio are incremented) is to go completely remove
>       libcdio* and libvcd* from /usr/local/lib (and perhaps libcddb if it
>       has been linked against libcdio) and do a complete rebuild of
>       libcdio --without-cd-info, build vcdimager, rebuild libcddb, then
>       rebuild libcdio --with-cd-info and then perhaps rebuild vcdimager
>       against the latest libcdio

Seems to be a common problem...

> I prefer the simpler method used by libquicktime - it's been
> libquicktime.so.0.0.0 forever :)  No trouble at all and I've never
> gotten hit with symbol versioning problems/glitches...

That's because nobody implemented it yet. When you e.g. get an application
as binary package linked with a (usually crippled) libquicktime from your
distribution and want the latest libquicktime on the same system,
you'll need library versions.

As long as you do it cleanly, symbol versioning is no problem.

Cheers

Burkhard