Re: Installation dirs in code

[Brendon Costa]

Brian Dessent wrote:

> Instead of using an absolute path, you can use a relative path, which
> makes the binary relocatable.  For Win32, this means you can avoid
> completely the hassle of converting between native and posix-emulated
> (aka MSYS/Cygwin) paths.  It also means the user can install your
> package into any location and have it work correctly, which is common
> accepted practice with most Windows software.  You need to base these
> relative paths on something fixed though, commonly the location of the
> binary itself.  See also:
>
> http://www.gnu.org/software/autoconf/manual/html_node/Defining-Directories.html
> http://autoconf-archive.cryp.to/adl_compute_standard_relative_paths.html
> http://lists.gnu.org/archive/html/bug-gnulib/2003-03/msg00020.html
>
>  
Thanks for the information. Those links helped me to understand the 
problem of creating relocatable packages a bit better. It seems that 
creating relocatable packages is very difficult to do portably.

Windows can use: GetModuleFileName() and you can then use that to obtain 
the bindir and find the other paths relative to bindir.

Linux can use: readlink("/proc/self/exe") which requires that proc have 
been mounted (On NetBSD it is not necessary to have /proc mounted and is 
not by default at least on my system. I assume that proc is not 
necessary for linux eithre so this would not work all the time. Also 
NetBSD would have to fall under Other UNIXes which must look at argv[0] 
as it has no /proc/self/exe that i can see)

Other systems have to make do with looking at argv[0] and the PATH env 
var, which may not necessarily work as argv[0] does not have to be the 
name of a program being run (although usually it is) and according to 
one FAQ i read (very unlikely) but the exe may have been deleted just 
after startup so searching for agv[0] in the path may fail for that 
reason too.

However all these methods of obtaining the directory information seems 
to fall down for libraries. Installing data with libraries is not often 
a good idea i guess but i am currently doing it for one of my libs. I 
cant see any way around this problem.

Any suggestions how I could obtain the directory in which a library was 
installed at runtime? Possibly search for the library file in the 
various lib dirs and also looking at LD_LIBRARY_PATH and then use that 
as the anchor dir calculating relative paths from libdir?

The links mentioned above were more focused on the relocation of shared 
libraries. For the moment i am happy to make the user export 
LD_LIBRARY_PATH as that also seems like yet another difficult problem.


One other issues that strikes me as possibly being a problem on those 
weird systems that install things a little different to normal could be 
if you configure with something like:

/path/to/configure --exeprefix=/usr/local --prefix=/home/bcosta

as the only common path between "/usr/local/bin" which would end up 
being the bindir value and "/home/bcosta/etc" is "/". I guess if the 
|adl_COMPUTE_STANDARD_RELATIVE_PATHS| macro computed the path for the 
exeprefixdir from the prefixdir as being "../../usr/local" then it would 
still work fine (Though relocation would be a bit strange to achieve). 
But I am not sure of how that macro is writen.

Gah this is a sticky problem...

> > When doing a cross compile
> > usually the installation prefix is not the name of the actual install
> > path that will be used on the end system, but just some temporary
> > directory that the binaries are compiled into before being copied across
> > to the host system later.
> >    
>
> That sounds seriously broken.  --prefix should always reflect the
> desired final location of the package, even if it does not exist on the
> build system.  If you need to use a temporary staging directory for the
> purposes of creating a distribution package, then the correct method is
> to override DESTDIR during the install phase, not to lie to configure
> about prefix, e.g.
>
>  

Thanks. I have been mis-understanding the meaning of the prefix. It also 
seems that i cant specify windows native paths in the prefix anyway if i 
was to use absolute paths. If i try, then the -rpath that seems to be 
emitted by libtool when creating a shared lib does not see C:\blah as an 
absolute path and so libtool emits an error, though this could be a bug 
with the MinGW cross port of libtool?

E.g. This fails to link an application that uses a libtool library.
/path/to/configure --prefix=C:\blah DESTDIR=/home/bcosta/staged/i386-mingw32


the error looks like:

/usr/pkg/bin/bash ../../libtool --tag=CXX --mode=link g++   -g -O2   -o 
libADS_System.la -rpath C:\msys\1.0\blah/lib -no-undefined 
-Wl,--enable-runtime-pseudo-reloc libADS_System_la-ADS_System.lo ... 
more objects

libtool: link: only absolute run-paths are allowed

I might send this report to the libtool mailing list.

Anyhow, thanks for the information and talking over this issue with me. 
I really would like to find a portable solution to this problem (Even if 
it is a bit ugly but can be wrapped in a consistent manner).

Thanks,
Brendon.