Patch: binary relocatability support for Gimp
This discussion is connected to the gimp-developer-list.gnome.org mailing list which is provided by the GIMP developers and not related to gimpusers.com.
This is a read-only list on gimpusers.com so this discussion thread is read-only, too.
Patch: binary relocatability support for Gimp | Hongli Lai | 07 Apr 20:45 |
Patch: binary relocatability support for Gimp | Sven Neumann | 09 Apr 15:15 |
Patch: binary relocatability support for Gimp
On Win32, Gimp is relocatable. It can find out it's own path at runtime and find out where it's data files are. On Linux, all paths in Gimp are hardcoded at compile time. This means the app is not relocatable.
I work for the autopackage project (http://autopackage.org/), a new
installation system for Linux. One of the features of autopackage is
that packages can be installed to any prefix (although that's not
recommended), which means the software must be relocatable. Because
there's no real easy way to quickly find out the path of a library or
application.
See also http://autopackage.org/docs/binreloc/ for more info about
BinReloc and the relocation problem.
Anyway, to the point. I'm packaging Gimp 2 currently and I've modified Gimp to be relocatable on Linux. The patch is mostly finished but there are still minor issues to take care of. I'd like to know if this patch is good enough to be able to get accepted, and if not, why.
Please note that adding binary relocation support on Linux will not harm portability! I wrote a configure check for this, and binary relocation support will be automatically disabled if the system is not running on Linux. The user can also explicitly tell configure to disable binreloc support.
I am aware that app/main.c sets LD_LIBRARY_PATH. This is just temporary because it's less work than modifying every Makefile for every plugin. Apart from this obvious hack, how does the rest of the patch look? Is it good enough to be accepted once I remove the LD_LIBRARY_PATH hack?
Patch: binary relocatability support for Gimp
Hi,
Hongli Lai writes:
On Win32, Gimp is relocatable. It can find out it's own path at runtime and find out where it's data files are. On Linux, all paths in Gimp are hardcoded at compile time. This means the app is not relocatable.
I work for the autopackage project (http://autopackage.org/), a new installation system for Linux. One of the features of autopackage is that packages can be installed to any prefix (although that's not recommended), which means the software must be relocatable. Because there's no real easy way to quickly find out the path of a library or application.
See also http://autopackage.org/docs/binreloc/ for more info about BinReloc and the relocation problem.Anyway, to the point. I'm packaging Gimp 2 currently and I've modified Gimp to be relocatable on Linux. The patch is mostly finished but there are still minor issues to take care of. I'd like to know if this patch is good enough to be able to get accepted, and if not, why.
Please note that adding binary relocation support on Linux will not harm portability! I wrote a configure check for this, and binary relocation support will be automatically disabled if the system is not running on Linux. The user can also explicitly tell configure to disable binreloc support.
I am aware that app/main.c sets LD_LIBRARY_PATH. This is just temporary because it's less work than modifying every Makefile for every plugin. Apart from this obvious hack, how does the rest of the patch look? Is it good enough to be accepted once I remove the LD_LIBRARY_PATH hack?
No. Your patch does not follow the GIMP coding style, breaks file naming conventions and duplicates code available in GLib. So we will not accept the patch as is. But if you could explain the problem and how the patch tries to solve it, we will consider to add code that solves the problem. But surely not this code. I understand that it is meant to be a generic solution suitable for all apps. But I am confident that the same change can be written in half the number of lines if glib is used for it and I would prefer a small change over a generic one.
I also very much dislike the fact that this is completely Linux specific and I would like you to explain the Makefile changes that would be necessary to get away without the LD_LIBRARY_PATH hack.
Sven