Re: Converting libraries and plugins to use gtk3
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 On 11/06/10 14:28, Alexander Larsson wrote: Any library that links to gtk+, gdk or gdk-pixbuf, that switches to gtk3 will need to have the new version be separate from and parallel installable with the old version. If this is not done then distributions can not ship applications still using gtk2 linking to the older version of the library, as this change is binary incompatible (and since you can't mix gtk2 and gtk3 in the same app). I'm sorry but may I ask for interpretation of the following text? I interpret that separate packages (as well as Gentoo developers responsible for GNOME packages) that it applies at package-level. However evolution-data-server developer(s)[1] thinks otherwise and believe it is sufficient if the only libraries linking to gtk+-3.0 (like libedataserverui-3.0.so) need the bumping and rest of packages bundled do not. It creates making a package harder, especially in source based distribution as it requires splitting package by hand and to resolve incompatibles between versions. Additionally one file (/usr/lib64/evolution-data-server-1.2/extensions/libecalbackendweather.so) have 2.x version (1.2) while linking to libgtk+-x11-3.0.so.0. Could anyone clarify (and reopen if appropriate) bug 623462[1]? Regards [1] https://bugzilla.gnome.org/show_bug.cgi?id=623463 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.15 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAwAGBQJMMg2IAAoJEJIdee2Vr4aP0CUP/0aP5KRVAjHH15Oh83M1A1vY BDWgvx2WjaWPXD5pth5s45yQmYq29YfBPSypMj8GGJ57y0Rz5kFLZtaA31Gli11s bOswBeoUS1cDIpLhACg95xhtAt7afFVt/F7BQ8xp2og6hP3p7KPUcgSvmRZY1B3y IBc0xX/7PMuvHCrM2zdjFwQcszoR1tkTMQqqTeF2RA+aVLry7f1y7VasnyzrqtvM rpt5aQxX5/fzlFO4VQeTa6qNYCajMAFyzjiknM6K1GL8B8CIoJ0h0JzhxfUH3q+V gCFRa17SKeuRoNZKMk+8ink4vg8KID+Ouckya7gNQH6Y6PZw3h+DBio6YbY3cpR5 fIMS4QIQkEK7fpFO75T9duPdPvykjVVkLI+4omBIdcRgugifs0g6gczE3Ai4lqCY gNr+IXau7MIclAA6Q1jJu5DEsGfEsx5p95BGWwNaFYP7oH/OorVQB5g2W0fL+8cP StaOiknxQ1OthaTdq5C/Cc7jtNIYdA/C+hfYI/oMnfsCFKtgLMsB2lEvHL9F005p wfEIS2Xgc5zsrvVIkFLh4IrQ1GjePfitqJfC4jsaWnJmFKp0ba2kb/wEUfruoqLa N3MyEPKunOXeWZzpKH5b8iQ5P2xJWQNrap+a25gl+9p4ySDUvtwrmobc7b4ZfmwR CSaJWKL63x2t2NpaGrG8 =0f0Q -END PGP SIGNATURE- ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Libtool versioning made easy (was Re: Converting libraries and plugins to use gtk3
On 06/11/2010 08:28 AM, Alexander Larsson wrote: * Reset the so version to 0:0:0 Those of you who've had to deal with libtool know that libtool versionin is a PITA. Here's a snippet to make libtool versioning (and as a result .so versioning) automatic based on your regular major.minor.micro version number (and assuming GNOME version conventions). I'm copying from vte. In your configure.ac: === m4_define([version_major],0) m4_define([version_minor],25) m4_define([version_micro],1) m4_define([version_triplet],version_major.version_minor.version_micro) m4_define([so_major_adjust],9) dnl Don't change! AC_PREREQ([2.59]) AC_INIT(vte, [version_triplet], [http://bugzilla.gnome.org/enter_bug.cgi?product=vte]) # Libtool versioning m4_define([lt_revision], m4_if(m4_eval(version_minor%2),1,0,version_micro)) m4_define([lt_age], m4_eval(version_minor*100+version_micro-lt_revision)) m4_define([lt_current], m4_eval(so_major_adjust+version_major+lt_age)) m4_define([lt_triplet],lt_current:lt_revision:lt_age) LT_VERSION_INFO=lt_triplet() AC_SUBST([LT_VERSION_INFO]) === In your src/Makefile.am add -version-info $(LT_VERSION_INFO) to your library's LDFLAGS. Update the so_major_adjust number such that your so_major matches whatever your library currently uses. For example, vte has a major version of 0, but so-major of 9, so we use a 9 so_major_adjust. The nice thing about this setup is that you get the library version number in the .so number. For stable releases, for example, vte-0.26.5, it will result in libvte.so.9.2600.5, and for unstable releases, for example, vte-0.25.5, it results in libvte.so.9.2505.0. One note though. When I implemented this scheme in cairo first, we got one report from some odd unix flavor that libtool had problems handling such large version numbers. I've been using it in vte and pango for quite some while by now though, and have not got any such reports. Filed bug 623238 to add this to gnome-common. behdad ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Libtool versioning made easy (was Re: Converting libraries and plugins to use gtk3
On 06/30/2010 04:26 PM, Adam Jackson wrote: On Wed, 2010-06-30 at 15:43 -0400, Behdad Esfahbod wrote: In your src/Makefile.am add -version-info $(LT_VERSION_INFO) to your library's LDFLAGS. Or you could just do it directly: libX11_la_LDFLAGS = -version-number 6:3:0 -no-undefined gives you libX11.so.6.3.0. Using straight major.minor.micro is actually a good idea too. Maybe we should do that. The only difference with my scheme is that my scheme assumes that individual releases in a devel series all add new interfaces whereas using major.minor.micro directly assumes that no point releases adds new interfaces (stable or not). Both assumptions are wrong, but mine is on the safe side. The only reason I like your proposal is that I don't think anyone makes any assumption about minor .so version anyway... behdad libtool very sensibly only really documents -version-info because, in this one instance, they chose to implement something so utterly orthogonal to any library versioning scheme ever seen in the wild as to be unusable, instead of their usual strategy of implementing something so lowest-common-denominator as to be unusable. - ajax ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Converting libraries and plugins to use gtk3
On Fri, Jun 11, 2010 at 8:28 AM, Alexander Larsson al...@redhat.com wrote: Any library that links to gtk+, gdk or gdk-pixbuf, that switches to gtk3 will need to have the new version be separate from and parallel installable with the old version. [ lots of good information elided ] Wow. Alex, you just sent out the mail that I've been drafting here... Just a few points I'd like to add: On the GTK+ modules front, we have made major progress in the last few days: at-spi2-atk builds modules for both, Bastien did a gtk-engines 2.90 release, and Lennart and Hiroyuki have committed dual-build patches for libcanberra and librsvg. That means GTK3 applications should pretty much work and look as expected, as far as loadable modules are concerned. Wrt. to libraries linking against GTK+, I want to point out that a fair number of these are obsolescent, and the ABI break is a perfect time to port from them to newer GTK+ and GLib features, e.g. libglade - GtkBuilder libsexy - various GTK+ features libgnomeui - various GTK+ features libunique - GtkApplication libbonoboui - port to dbus, use GDBus The GTK+ api docs contain migration hints on many of these: http://library.gnome.org/devel/gtk/stable/migrating.html http://library.gnome.org/devel/gio/2.25/migrating.html ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
