automake
[Top][All Lists]
Advanced

[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 18:03:32 +1100
User-agent: Mozilla Thunderbird 1.0.7 (X11/20051204)

Brian Dessent wrote:

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

Hmm. I guess I didnt read it carefully enough. For the argv[0] case (Which would occur on my system as i use NetBSD) i guess there are a few restrictions that apply, but they dont seem like much of a problem.

I had a look at gnulib and it seems that Bruce Haible's code is in it (At least it is mentioned in the ChangeLog). Just have to figure out how to use it now :-) Ive never used gnulib before. But thanks for putting me on the right trail.



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.

sorry i meant --exec-prefix so the binaries in one root and the data/configuration in another. Yes, if installing in that strange way, then users relocating data would need to take that into account in that the two roots would most likely need to be relocated together.


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

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.

I think i will look into this a bit more and take it to the libtool list, but it could have something to do with the fact that i am cross compiling and for some reason (Like my configuration) libtool is not thinking in win32 mode but in UNIX mode and so is emitting the -rpath because the build machine is UNIX, even though the host machine is win32.


Thanks again for all the help.
Brendon.






reply via email to

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