Re: Installation dirs in code

[Brian Dessent]

Brendon Costa wrote:

> However all these methods of obtaining the directory information seems
> to fall down for libraries.

Huh?  Did you read the same email by Bruce Haible that I did?  Because
it doesn't fall down at all.  On Win32 GetModuleFilename works just fine
to tell you the DLL name, and you can even do this in DllMain so that
the value can be computed when the DLL loads and before any functions
are called.  (Note that you have to be very careful about what you do in
DllMain, the APIs available are very limited.)  And on Linux you can
parse /proc/self/maps to get the shared library location.  On other
platforms, you just accept the restriction that L and P have to be
relocated together and use argv[0], and in the case of a statically
linked library there is no separate library name to find so it's also
just argv[0].  This just means you need to add this to your library's
API, as in it becomes a parameter of whatever kind of "init_my_library"
function you call, or add some kind of "set_program_name" function that
you require to call before doing anything else.

Or as he put it, "So we implement a solution for 4c) on all platforms
and for 4a) on Linux, Woe32."

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

I don't know what you mean by this "exeprefix" but in general I suspect
the relative paths would descend down to the root and then back up,
which would make relocation fail if an extra directory level was added. 
But the user would have to accept any such strangeness as an effect of
such a nonsensical configuration with two conflicting options given.

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

This is a very common thing to do on MSYS, and it should work.  You will
see the idiom "configure --prefix=`cd /posix/path && pwd -W`" all over
the place as this is a quick way to convert /posix/path to its actual
Win32 path if the package hard codes it in the binary in any way.

> 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

But this is wrong.  You don't specify DESTDIR to configure.  You only
override it in the make invocation during the install step.  I'm not
sure if this is the cause of the error you're seeing though.

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

I'm not entirely sure what's going on here, but rpath isn't even
relevant for Win32 anyway so it's kind of strange.

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

Again, check out Bruno Haible's code in gettext, as he already solved
this problem in a cross-platform manner.  I don't know if his code has
also been added as a gnulib module for easy reuse.

Brian