Re: hardcoded dependencies problem with building/installing GTK+

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

_______________________________________________
gtk-list mailing list
gtk-list@xxxxxxxxx
http://mail.gnome.org/mailman/listinfo/gtk-list

[Index of Archives]     [Touch Screen Library]     [GIMP Users]     [Gnome]     [KDE]     [Yosemite News]     [Steve's Art]

  Powered by Linux