[Top][All Lists]

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

Re: Installation dirs in code

From: Brendon Costa
Subject: Re: Installation dirs in code
Date: Wed, 13 Dec 2006 14:50:23 +1100
User-agent: Mozilla Thunderbird 1.0.7 (X11/20051204)

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:

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]