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

[R. Bernstein]

Uncle! (U.S. slang for "I give up" -- often used in arm wresting).

It is clear that using libvcdinfo in cd-info causes too much grief for
too many people, with not all that much benefit. Clearly this was a
bad mistake on my part - I'm sorry.

If I've done things right, I've just set the configuration script to
disable this by default. If I haven't done this properly feel free to
go and correct.

As for how to build things. One way is to configure libcdio and
build/install just the libraries. Then build vcdimager and go back
build/install the rest. 

Although there is no circular dependency, it's how things are packaged
that makes it feel that way. libcdio libraries are at the lowest level
and some packagers have a libcdio-libs. Or a libcdio without the
utilities. cd-info which is a utility program *optionally* depends on
vcdimager libraries.

There is corresponding program in vcdimager, vcd-info, which does what
cd-info does in the area of VCD information. However it doesn't give
as much raw CD information.


address@hidden writes:
 > 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
 > 
 > 
 > 
 > _______________________________________________
 > Libcdio-devel mailing list
 > address@hidden
 > http://lists.gnu.org/mailman/listinfo/libcdio-devel
 >