Re: PATCH mingw32 MD_STARTFILE_PREFIX was a bad idea.

["Aaron W. LaFramboise" <aaronraolete36 at aaronwl dot com>]

Daniel Jacobowitz wrote:
> On Thu, Jun 10, 2004 at 10:20:10PM -0500, Aaron W. LaFramboise wrote:
> > As near as I can tell, the only way to fix this is to remove this macro 
> > and give up being able to install a mingw GCC to any directory.  This 
> > means having to install the libc (mingw runtime or otherwise) into any 
> > directory you'd like to install GCC into before you build GCC.
> Can't you do this by overriding STANDARD_STARTFILE_PREFIX or so?

I *think* changing STANDARD_STARTFILE_PREFIX will mess up GCC's install 
tree relocatability in Windows.  (I don't quite understand the logic in 
gcc.c.)  That is, presently, an entire GCC can be copied to a different 
directory, and everything will still work.  This sort of functionality 
is important on Windows.

What's really needed, in my opinion, are macro equivalents to 
standard_startfile_prefix_1 and standard_startfile_prefix_2, which 
specify "/lib/" and "/usr/lib/" respectively.  In addition to helping 
GCC find MinGW libraries in the right place, these macros would also 
prevent searching /lib, which quite possibly may cause subtle bugs if it 
exists and has something in it.

Unfortunately, even this is not ideal, as hard coding paths in this 
manner is almost certainly always wrong, in general, on Windows.  I 
don't think theres anything one can do about this, though, short of 
using something like the registry key support (which I understand may 
disappear soon).

So, would it be appropriate to add the target macros 
STANDARD_STARTFILE_PREFIX_1 and STANDARD_STARTFILE_PREFIX_2?  They make 
more sense as macros than hooks because standard_startfile_prefix_1 and 
standard_startfile_prefix_2 are const.

Aaron W. LaFramboise