[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Libcdio-devel] cd-info linking conflict
From: |
Steven M. Schultz |
Subject: |
Re: [Libcdio-devel] cd-info linking conflict |
Date: |
Wed, 29 Nov 2006 15:53:54 -0800 (PST) |
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