On Wed, Dec 3, 2008 at 11:21 AM, Thomas Kuehne <[EMAIL PROTECTED]> wrote:
> On Wednesday 03 December 2008, Jonathan S. Shapiro wrote: > > > It seems to me that if the *discovered location* of the bitcc > > executable matches the location specified to configure, then we > > should assume that the value of LIBDIR provided by configure are > > correct.The reason we need to do this is that we need to be able to > > honor perverse uses of configure when the package is *not* > > relocated. > > And that's where autoconf strikes, LIBDIR isn't known during > "make all". > > configure: > # Installation directory options. > # These are left unexpanded so users can "make install > # exec_prefix=/foo" and all the variables that are supposed to be > # based on exec_prefix by default will actually change. So I sat down to deal with this today. Prior to autoconf 2.60, the exec_prefix value was expanded, and it looks to me like the autoconf people have completely busted absolutely everything with this change. The problem with letting the user re-write exec_prefix at install time is that the installed binary then has absolutely no idea at run time what the correct value of exec_prefix is. On reading some of the discussion, it appears to me that this is intentional, and that the value of exec_prefix used at install time is used purely for installation path establishment, and if it differs from the value used at compile time then the responsibility to sort out what happened rests entirely with the user. So for the moment, what I've done is add the *expanded* value of LIBDIR to the internal libDir search path. This at least allows the install location to be set statically and then used. This is done unless --nostdlib is specified. The problem with looking dynamically is that if the user supplied both libdir and bindir then looking dynamically won't generate a sensible answer.
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
