Michael Ekstrand wrote: > You might want to take a look at what the autopackage folks are doing. > At the very least, they have a lot of documentation on what's required > to prepare relocatable, portable binary packages. > Anyway the GTK hardcoded path are not a good thing IMHO. With some care and the use of -rpath linker option and LD_LIBRARY_PATH you can ship linux binaries using a wide library range.
I've shipped a commercial game with ogre, cegui, sdl, devil, boost, libjpeg/png/tiff, libstdc++ and other stuff, but the installer (loki) that use GTK, should stay compatibile with gtk 2.0.x and gtk 1.2.x (there are two versions) cause there is no reliable way to ship gtk statically linked or in a particular path (for the installer for instance a CDROM relative path). Having relative paths in the gtk core libraries what problem could cause? In windows paths are relative so I suppose this could work also on linux, maybe there will be some rework in the autoconf/make scripts at most :) Eg make libgtk-2.0.so try to load: ./gtk-2.0/2.10.0/loaders/libpixbufloader-gif.so Instead of: /usr/lib/gtk-2.0/2.10.0/loaders/libpixbufloader-gif.so Bye, Gabry _______________________________________________ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
