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. [EMAIL PROTECTED] 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 > [email protected] > http://lists.gnu.org/mailman/listinfo/libcdio-devel > _______________________________________________ Libcdio-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/libcdio-devel
