Hi Tor,
Thanks for your response.
Please see my comments below in line start with [maggie].
On Wed, Aug 19, 2009 at 7:37 AM, Tor Lillqvist <tml@xxxxxx> wrote:
> 1. "configure --prefix=my_build_dir"This probably is a stupid question, but why didn't you run configure
> 2. "make"
> 3. "make install".
> 4. cp my_build_dir/lib my_install_dir/lib
--prefix=my_install_dir then?
Yes, using "configure --prefix=my_install_dir" would have solved all the problems. But we can't write to my_install_dir from the host where we do the build. my_install_dir is a mirrored filer which has mirroring sites around the world. Only one host can write to the master location.
Yes. That is how GTK+ (and lots of other software) works on Unix
> But I'm now facing with another problem. The application would try to look
> for "my_build_dir/etc/gtk-2.0/gdk-pixbuf.loaders" and
> "my_build_dir/etc/pango/pango.modules" and complains when not found.
systems: there are hardcoded paths to run-time files in the binaries.
This is usually not a problem. (The situation is vastly different on
Windows, of course. And indeed the GTK+ stack does not use hardcoded
paths on Windows.)
Can you explain what kind of Unix system it is that you intend to
deploy your build of GTK+ on, if you can't know beforehand what the
actual installation root will be? Is it not even possible to install a
symbolic link as the configure-time prefix, pointing to a different
installation root?
[maggie] We are building on RedHat Linux. The system default GTK+ (at /usr/lib) is too old and our application requires newer version.
If that's a common practice for GTK+ (and other software) to hardcode runtime paths in them, I guess we will have to make sure my_install_dir is same as my_build_dir. This might imply that we may need to use symlinks on the build host for that purpose.
We were on the wrong assumption that the privately built GTK+ librarary can be portable using LD_LIBRARY_PATH. But that seems to be a wrong assumption.
I guess what you don't tell us is that you don't know my_install_dir
> How to prevent my_build_dir from being written into the library? In
> particular, how could I make my application look for the gdk-pixbuf.loaders
> and pango.modules in my_install_dir instead of my_build_dir?
beforehand, that it will perhaps be different on each machine?
[maggie] Yes. We were expecting that we don't have to know/determine my_install_dir at the build time. From my understanding now, if my_build_dir is expected to be same as my_install_dir. And should my_install_dir has to change, we would have to rebuild/reinstall GTK+ again to the new path. Is that correct understanding?
However, since only our application requires the newer GTK+ library, if we want to deploy GTK+ along with our application, we would not have to know before hand where my_install_dir would be. How do people solve this kind of problem then?
Thanks again!
Maggie
Maggie
--tml
_______________________________________________ gtk-list mailing list gtk-list@xxxxxxxxx http://mail.gnome.org/mailman/listinfo/gtk-list
