[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Installation dirs in code
Re: Installation dirs in code
Wed, 13 Dec 2006 14:50:23 +1100
Mozilla Thunderbird 1.0.7 (X11/20051204)
Brian Dessent wrote:
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.
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:
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
as it has no /proc/self/exe that i can see)
Other systems have to make do with looking at argv and the PATH env
var, which may not necessarily work as argv 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 in the path may fail for that
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 ...
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).