Hi! On Sun, 2010-06-20 at 23:24 +0200, Pavel Kankovsky wrote: > > Put them elsewhere and use PKG_CONFIG_PATH when you need them.
Right, I didn't think about it, might be an option... > What symlinks? Do you mean things like libQtCore.so.4 (ie. the soname) > pointing at libQtCore.so.4.2.1 (ie. the real filename)? If the new version > ABI is not upward compatible with the old version bundled in the distro > but the new version builds with the same sonames by default then the right > solution is to change the soname of the new version. Yep. No, usually the ABI is not upward compatible. I am not familiar with dynamically linked libraries management on Linux. What do you mean by "change the soname"? Shall I just rename the so to libQtCore.so.4.5.4 and remove the synlinks? > > This all looks very very dirty to me and the static solution is way much > > cleaner, it's just that one needs time to implement it properly. > > It does not scale up very well, IMHO. Oh really? What would be the potential problems that I'd face? Actually I have never built static versions of Qt on Linux, but I did so on Windows and the size of the resulting executables was in the range of few Mbs which will be definitively a hardly noticeable increase. All it would take is to add a static blob in the SPEC in %build to build Qt just as I did for curl / rtorrent and what was later accepted as a more or less universal solution for backporting packages that require few libraries that are impossible to update globally... -- Sincerely yours, Yury V. Zaytsev _______________________________________________ suggest mailing list [email protected] http://lists.rpmforge.net/mailman/listinfo/suggest
