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

[Steven M. Schultz]

On Thu, 30 Nov 2006 address@hidden wrote:

> I want to install the current CVS to /opt/gmerlin, but I have an older
> libcdio in /usr/local (installed it for vcdimager I guess).

        You're in for a troublesome install ;)

        I've been battling the circular dependency between vcdimage and
        libcdio for a long time.

                ...

> 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.

>         /-> libcdio.so (newly installed)
> cd-info
>         \-> libvcdinfo.so -> libcdio.so.X (already installed)
> 
> How can one solve this?

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

        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

        That's why I shudder a little when ever the version number(s) get
        bumbed in libcdio (or ffmpeg's libav* stuff).  

        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...

> IMO the only possibility is to remove any reference to libvcdinfo
> from libcdio and move the vcdinfo related functionality from cd-info
> to a similar tool in the libvcdinfo package. But maybe someone proves
> me wrong :)

        Yep, cd-info is the trouble child.  Moving it to vcdimager would, I
        agree, probably solve the problem.

        Cheers,
        Steven Schultz