Hi! On Wed, 2010-06-23 at 20:28 +0200, Pavel Kankovsky wrote: > On Mon, 21 Jun 2010, Yury V. Zaytsev wrote: > > > Yep. No, usually the ABI is not upward compatible. > > Hmm... it is probably compatible (or is supposed to be) in this case > at least up to 4.4.3.
Well, that's true, but we would really want to have at least Qt 4.5 if not 4.6 for our purposes. Many packages nowadays require at least Qt 4.5 and if we limit ourselves to 4.4 to be backwards compatible, it means that most of these porting efforts do not make much sense. > A common convention is to use "library.so.1" (where 1 is the generation of > ABI) as a soname and "library.so.1.2.3" (where 1.2.3 is the version of the > library) as a filename, and to let ldconfig symlink soname to filename. Thanks you very much for an exhaustive explanation. Now I more or less understand what you are talking about. Still, I guess I need to Google quite a bit to see how to implement this in practice... ... but still, I am not convinced that this is the way to go. > Qt is a big library. Much bigger than SQLite or libcurl. You'd get > 1. bloated source packages, 2. slow rebuild times, and 3. bloated binary > packages if you bundled a private copy of Qt with every package needing > it. I know this. However, as I stated, I did static builds on Windows with mingw and the resulting binaries using basic Qt stuff were in the range of 1-2 Mbs. Do extra 1-2 Mbs really matter when you are talking about a monstrous 25 Mb worth of libs of vlc? > Issues 1 and 2 might be eliminated if there was a standalone > static-library-only devel package of Qt (and perhaps a small runtime > package if any data files are needed). Yes, this is what I was suggesting to do in view of these two problems. And I might even actually get some time one day to get to it... -- Sincerely yours, Yury V. Zaytsev _______________________________________________ suggest mailing list [email protected] http://lists.rpmforge.net/mailman/listinfo/suggest
