RSS/Atom feed Twitter
Site is read-only, email is disabled

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.

2 of 2 messages available
Toggle history

Please log in to manage your subscriptions.

Patch: binary relocatability support for Gimp Hongli Lai 07 Apr 20:45
  Patch: binary relocatability support for Gimp Sven Neumann 09 Apr 15:15
Hongli Lai
2004-04-07 20:45:54 UTC (about 20 years ago)

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?

Sven Neumann
2004-04-09 15:15:42 UTC (about 20 years ago)

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