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
