GNOME Bugzilla – Bug 672100
gimptool gives wrong admin plugin directory on 64-bit platforms
Last modified: 2013-07-05 15:02:29 UTC
The GIMP_PLUGIN_DIRECTORIES autoconf macro uses gimptool to determine plugin install directories, in this way: gimptool -n --install-admin-bin dummy On x86_64 platforms, this command returns /usr/lib/gimp/2.0/plug-ins However, this directory does not exist — GIMP is installed in /usr/lib64/gimp/2.0/plug-ins instead. This prevents configure scripts for gimp plugins from working properly.
Created attachment 248377 [details] [review] gimptool returns wrong system plugin dir if libdir has been customized. Hi, actually by default, the GNU libdir would be $prefix/lib/ but most distribution would use $prefix/lib64/ instead, mainly so that they can mix 32 bits and 64 bits package, I think. So basically packagers would use the --libdir=/usr/lib64 option of the configure script. And that's why you had this issue, because it seems gimptool tries to figure out the libdir instead of using the one set at compile time. The attached patch fixes this. Just waiting for someone to check it. :-)
In the spirit of get_runtime_prefix(), shouldn't it be: pkg-config --variable=libdir gimp-2.0
Hi, well I thought about it when I saw such code. But: 1/ I personally think this is a little absurd. This path is known at compilation time. Why would we add an indirection (actually even 2: pkg-config call into a shell) to an external pkg-config call while we could have direct access to the same path as a constant string (and in a much safer way than an external call, as a side note)? 2/ As a general thing, pkg-config is a compilation/linking tool. It is necessary for building GIMP, but should we really make it necessary for runtime too? I really disagree about making pkg-config a runtime dependency when we can avoid it. Ok here I understand that gimptool is a tool to build gimp plugins as well. So for this use case, maybe that makes sense to have pkg-config as runtime dependency. But that should not mean we should overuse it. 3/ Exceptionally if you have several GIMP installed, pkg-config may get you a wrong result. Well it happened to me yesterday when I was testing because I had a different order of directories in my PKG_CONFIG_PATH as in my LD_LIBRARY_PATH. So `pkg-config --variable=libdir gimp-2.0` returned me /usr/lib64/ (my packaged GIMP) instead of the expected dev version libdir, even though when running the dev version, it would actually not look into /usr/lib64/. As a matter of fact, there is no easy automatic way to tell pkg-config which GIMP we want info for (there are manual ways when you know how your system is set). Of course that will never happen to normal users who don't install several instances in several prefixes at once. That was also somehow an environment bug as my env variables were inconsistent with one another. But that still proves that we are adding a level of uncertainty, which is completely unnecessary. In *some conditions*, pkg-config may not return the value we want (the one which will be actually used when GIMP will be run), because it makes a runtime computation which is different from the one GIMP will do. Why take the risk? Why use different logics in GIMP and gimptool? LIBDIR on the other hand will always return the right value. :-) Well that's my case for this. Now if you really prefer using pkg-config even with this case, you're the boss. ;-)
As on IRC, Mitch told me he "gave" me gimptool (a poisoned gift, I guess :p), I push my patch as is on master and gimp-2-8. commit 97d14ebda3d5790b92f8bfa2a4b3291ccb9289e6 Author: Jehan <jehan@girinstud.io> Date: Thu Jul 4 22:11:47 2013 +0900 Bug 672100: gimptool returns wrong system plugin dir if libdir has been customized. On UNIX platforms, use the actual libdir value, which has been set at compile time.