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
