Re: Absolute paths

[Drazen Kacar <dave srce hr>]

Peter Astrand wrote:

> (Has this topic already been discussed?)

I think so, but not in depth.

> IMHO, Unix applications should never have hard-coded file paths embedded
> into binaries. Thus, binaries should still work if you move them. 

That's a worthy goal.

> It would be great if Gnome worked this way. The binaries for Solaris 2.7
> provided by HelixCode, for example, have /opt/gnome hardcoded, and this is
> not where I want to / can install Gnome. I'd like to run:

I can explain how to achieve this on Solaris, but the current build tools
don't make it possible.

A bug in HelixCode Solaris binaries is that they rely on LD_LIBRARY_PATH
to be set. That's deprecated for years, doesn't work in all cases you'd
want if it's your only option (it never did and never will). The primary
reason for keeping it in Solaris is that broken applications don't work
without it.

Some of the reasons why LD_LIBRARY_PATH should be avoided can be found
at <URL:http://www.visi.com/~barr/ldpath.html>. There is more than that.

The proper way to link binaries is to use -R flag. One usually puts
an absolute path here, but then the libraries won't be relocatable.
On Solaris you can use `-R $ORIGIN/../lib'. That way you can have
binaries in $prefix/bin and libraries in $prefix/lib. As long as you
keep them under the same $prefix, the apps will be able to find the
libraries.

However, performing

LDFLAGS='-R$ORIGIN/../lib' ./configure

is not going to work. Solaris 8 has configuration file for run-time linker, so
you could use it instead of $ORIGIN on that release. But it can get rather
messy and $ORIGIN is a much cleaner solution.

Another problem is called "the location of configuration files." The usual
way of dealing with this is requiring some environment variable to point
at the appropriate place. It works, but it's messy. A better way is to put
a small function in every application and library which has configuration
file(s).

Apps can use getexecname() to determine their prefix.

Libraries should have a function in their .init section which should determine
$prefix under which the library is installed and then determine the appropriate
location for the config file. Care should be taken because of installations
on NFS servers (so called application servers).

If one puts an application under /opt/gnome/bin on a server, then the config
file could live in /opt/gnome/etc. However, then each host that mounts
applications won't have the option of changing local configuration.
Therefore I think an exception should be made if $prefix starts with `/opt'.
If that's the case (and our $prefix now looks like /opt/foo), config file
should first be searched in /etc/opt/foo and then in /opt/foo/etc.
That way each host can have local configuration in /etc/opt (which is
a standard SYSV location for config files) and if it's not there it can
inherit whatever is on the application server. Some environment variable
can still override the location, of course.

However, libtool is not going to let you put anything in .init section.
In fact, libtool is not capable of linking shared libraries correctly on
Solaris at all, although most of them appear to work fine. It's just a
trick of the light, though.

> , for example, but as far as I understand, this is not possible. Can this
> be fixed? 

It's easy to write the code for apps and libraries. Fixing build tools
is the hard part.

> Btw, HelixCode have different SRPMS for different archs. Why? 

Dunno.

-- 
 .-.   .-.    I don't work for my employer.
(_  \ /  _)
     |        dave@srce.hr
     |        dave@fly.srk.fer.hr