Re: hardcoded dependencies problem with building/installing GTK+

[Qing Men <maggie eclipse gmail com>]

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 iki fi> wrote:

> 1. "configure --prefix=my_build_dir"
> 2. "make"
> 3. "make install".
> 4. cp my_build_dir/lib my_install_dir/lib

This probably is a stupid question, but why didn't you run configure
--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.

 

> 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.

Yes. That is how GTK+ (and lots of other software) works on Unix
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.

 

 

> 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?

I guess what you don't tell us is that you don't know my_install_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

--tml