GNOME Bugzilla – Bug 147662
Gimp shouldn't use deprecated RSVG APIs
Last modified: 2005-05-02 18:59:55 UTC
plug-ins/common/svg.c calls rsvg_handle_set_dpi from librsvg/rsvg.h. A commit of rsvg.h on July 10 changed rsvg_handle_set_dpi: -void rsvg_handle_set_dpi (RsvgHandle * handle, double dpi); +void rsvg_handle_set_dpi (RsvgHandle * handle, double dpi_x, double dpi_y); svg.c therefore fails to compile on Solaris, with a prototype mismatch error: "svg.c", line 373: prototype mismatch: 2 args passed, 3 expected "svg.c", line 469: prototype mismatch: 2 args passed, 3 expected Attached patch changes vals->resolution to vals->width and vals->height though this may not be the correct thing to do (though it now compiles on my Solaris systems).
Created attachment 29558 [details] [review] Change svg.c to match function prototype change in librsvg
The librsvg developers should be more careful and should avoid changing the API. It looks like the change is in CVS only and not in a released version. It also looks as if the version number hasn't been increased when this API change was made. We can thus not do anything about it. I am reassigning this GIMP bug-report to librsvg. I suggest that the API change is reverted and instead a new function is added that allows to change the horizontal and vertical resolutions independently.
API change reverted, new function added. as far as i know, librsvg is part of the "desktop" platform and thus has no guarantee of API/ABI stability. but i'll bend here. old APIs marked as deprecated. reassigning bug to GIMP to not use deprecated APIs.
Well, we can hardly depend on an unreleased version of librsvg but we could use the new API conditionally.for GIMP 2.2.
Comment on attachment 29558 [details] [review] Change svg.c to match function prototype change in librsvg The patch needs to test against the rsvg version installed, and use the new API conditionally.
This sucks. If we use the new API conditionally we make it impossible to use the binary which is compiled against a newer version of librsvg on a machine where an older version is installed. We will postpone this change until the new API is commonly available.
Would it be okay to fix this by adding a configure check for the librsvg version? I'll be happy to code it up if that is acceptable.
Uh, this is a one line change to configure.in (change rsvg_required_version to version number where the new API was introduced)
If we took that approach, it would mean requiring at minimum librsvg 2.8, which was released September 2004. Would that be acceptable?
That's the approach Sven suggested. I think it's fine for HEAD.
Yea, we also require GTK 2.6, which was released much later.
In HEAD: 2005-03-22 Bill Skaggs <weskaggs@primate.ucdavis.edu> * configure.in: raise required librsvg version to 2.8.0 * plug-ins/common/svg.c: change deprecated librsvg api, fixes bug #147662.
FYI, they have changed name of rsvg_handle_set_dpi_x_y back to rsvg_handle_set_dpi in cvs.
Does that mean that the plug-in doesn't compile against current CVS of librsvg then?