Re: PING [4.1 regression, patch] build i686-pc-mingw32

[Christopher Faylor <me@cgf.cx>]

On Wed, Jul 20, 2005 at 10:25:06PM -0400, DJ Delorie wrote:
>> Except that "cp" is already used as a fallback for when "ln" doesn't
>> work.  If the tool is likely not to work after a "cp" then shouldn't the
>> fallback condition be to always create a shell script (or .bat file)?
>
>One could argue that, in the case with ln/cp, we *know* we're dealing
>with GNU tools which don't care where they are, but in the case with a
>system (i.e. third party) tool, we don't know, hence the script.

Is that actually true, though?  Doesn't GNU ld try to locate files
relative to its invoked path?

Is there a non-GNU ld out there which needs to reference things relative
to its path?

>There's also the complexity of locating a utility in $PATH, which may
>even change between configure and make.
>
>IMHO for MinGW, we (1) know that we're using GNU tools, and (2)
>realize we have an exceptional situation wrt the build system.  I
>think this justifies an exception test in that snippet of code.

I hate seeing this kind of system exception in code.  As much as I like
MinGW, this is one of the things that bugs me about it.  Adding
window-isms to code can be like a creeping fungus.

Danny Smith said this:

>I just configure using --with-as=/path/to/original-as-for-target and I
>don't run into the problem.

Since we know that mingw uses GNU ld couldn't we prewire this action
into configure by default and avoid the need for this kind of
system-specific behavior in the makefile?

cgf