This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


On Wed, Jul 20, 2005 at 10:40:39PM -0400, Christopher Faylor wrote:
> 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?

Yes, that's correct.

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

This I don't know the answer to.

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

On other systems, this makes the GCC build not relocatable at install
time.  I don't know if that is true on mingw32 also, but I presume so.

-- 
Daniel Jacobowitz
CodeSourcery, LLC


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]