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

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

[FX Coudert]

PING. Could one of the mingw/cygwin maintainers review this patch? Or 
can someone else do it?

http://gcc.gnu.org/ml/gcc-patches/2005-07/msg00086.html

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

[Christopher Faylor]

On Tue, Jul 19, 2005 at 11:07:33AM +0200, FX Coudert wrote:
>PING. Could one of the mingw/cygwin maintainers review this patch? Or 
>can someone else do it?
>
>http://gcc.gnu.org/ml/gcc-patches/2005-07/msg00086.html

I'd prefer that Danny review this but neither of us has the right to
approve this patch.

However, it seems like you're adding extra stuff to the Makefile where
it is already trying to do the right thing if $(LN) fails.  Couldn't LN
just be declared as "cp" for mingw or, alternatively, couldn't it be
defined as some failing command so that the cp in the failing condition
would be invoked?

cgf

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

[FX Coudert]

> I'd prefer that Danny review this but neither of us has the right to
> approve this patch.

Well, then, who has the right to approve such a patch?

> However, it seems like you're adding extra stuff to the Makefile where
> it is already trying to do the right thing if $(LN) fails.  Couldn't LN
> just be declared as "cp" for mingw or, alternatively, couldn't it be
> defined as some failing command so that the cp in the failing condition
> would be invoked?

Well, perhaps I wasn't clear enough on what is the problem:

-	case "$<" in \
-	  ./*) ;; \
-	  ../*) \
-	     echo $(LN) $< as$(exeext); \
-	     $(LN) $< as$(exeext) || cp $< as$(exeext) ;; \
-	  *) echo '#!$(SHELL)' > as; echo 'exec $< "$$@"' >> as ; \
-	     chmod +x as ;; \
+	case "$(build)" in \
+	  *mingw32*) \
+	    cp $< as$(exeext) ;; \
+	  *) \
+	    case "$<" in \
+	      ./*) ;; \
+	      ../*) \
+	        echo $(LN) $< as$(exeext); \
+	        $(LN) $< as$(exeext) || cp $< as$(exeext) ;; \
+	      *) echo '#!$(SHELL)' > as; echo 'exec $< "$$@"' >> as ; \
+	        chmod +x as ;; \
+	    esac \

The cases with ./*) and ../*) already well handled, and just kept "as 
is" when $(build) is mingw32. The $(LN) command succeeds, that's not the 
problem.

Only the remaining case, which creates a shell script, fails on mingw32. 
The shell script is spawned to call the assembler, which fails. Only 
real win32 executables can be spawned.

FX

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

[Christopher Faylor]

On Tue, Jul 19, 2005 at 10:03:14PM +0200, FX Coudert wrote:
>>I'd prefer that Danny review this but neither of us has the right to
>>approve this patch.
>
>Well, then, who has the right to approve such a patch?
>
>>However, it seems like you're adding extra stuff to the Makefile where
>>it is already trying to do the right thing if $(LN) fails.  Couldn't LN
>>just be declared as "cp" for mingw or, alternatively, couldn't it be
>>defined as some failing command so that the cp in the failing condition
>>would be invoked?
>
>Well, perhaps I wasn't clear enough on what is the problem:
>
>-	case "$<" in \
>-	  ./*) ;; \
>-	  ../*) \
>-	     echo $(LN) $< as$(exeext); \
>-	     $(LN) $< as$(exeext) || cp $< as$(exeext) ;; \
>-	  *) echo '#!$(SHELL)' > as; echo 'exec $< "$$@"' >> as ; \
>-	     chmod +x as ;; \
>+	case "$(build)" in \
>+	  *mingw32*) \
>+	    cp $< as$(exeext) ;; \
>+	  *) \
>+	    case "$<" in \
>+	      ./*) ;; \
>+	      ../*) \
>+	        echo $(LN) $< as$(exeext); \
>+	        $(LN) $< as$(exeext) || cp $< as$(exeext) ;; \
>+	      *) echo '#!$(SHELL)' > as; echo 'exec $< "$$@"' >> as ; \
>+	        chmod +x as ;; \
>+	    esac \
>
>The cases with ./*) and ../*) already well handled, and just kept "as 
>is" when $(build) is mingw32. The $(LN) command succeeds, that's not the 
>problem.
>
>Only the remaining case, which creates a shell script, fails on mingw32. 
>The shell script is spawned to call the assembler, which fails. Only 
>real win32 executables can be spawned.

Ok.  Given that 'cp' was an acceptable fallback in the original version
of the above script, I wonder why 'cp' wasn't used instead of creating a
shell script wrapper.

cgf

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

[Daniel Jacobowitz]

On Tue, Jul 19, 2005 at 04:14:04PM -0400, Christopher Faylor wrote:
> Ok.  Given that 'cp' was an acceptable fallback in the original version
> of the above script, I wonder why 'cp' wasn't used instead of creating a
> shell script wrapper.

Because it is desirable to leave the tools where they were: they may
know about paths relative to where they are installed.  "as" is not the
interesting case here; "ld" is.  If configured properly, GNU ld will
look for libraries relative to its install directory - very useful for
building cross toolchains.  Or some third party linker may load DLLs
relative to its install path.

I'd say that using cp for mingw32 is not a huge step backwards.  If
someone triggers a failure case, then we can do more work on it then.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

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

[Christopher Faylor]

On Tue, Jul 19, 2005 at 04:21:04PM -0400, Daniel Jacobowitz wrote:
>On Tue, Jul 19, 2005 at 04:14:04PM -0400, Christopher Faylor wrote:
>>Ok.  Given that 'cp' was an acceptable fallback in the original version
>>of the above script, I wonder why 'cp' wasn't used instead of creating
>>a shell script wrapper.
>
>Because it is desirable to leave the tools where they were:

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

cgf

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

[Daniel Jacobowitz]

On Wed, Jul 20, 2005 at 10:10:03PM -0400, Christopher Faylor wrote:
> On Tue, Jul 19, 2005 at 04:21:04PM -0400, Daniel Jacobowitz wrote:
> >On Tue, Jul 19, 2005 at 04:14:04PM -0400, Christopher Faylor wrote:
> >>Ok.  Given that 'cp' was an acceptable fallback in the original version
> >>of the above script, I wonder why 'cp' wasn't used instead of creating
> >>a shell script wrapper.
> >
> >Because it is desirable to leave the tools where they were:
> 
> 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)?

That's basically what it does now; the only case which uses ln || cp is
for tools in the build directory, in which case they obviously are not
in their install location.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

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

[DJ Delorie]

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

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.

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

[Christopher Faylor]

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

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

[DJ Delorie]

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

Sometimes, for sysroots and ldscripts.  I wouldn't expect MinGW (or
any native linker) to use this feature.  GCC usually passes ld
whatever path specifications it needs.

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

A thought occurs to me... we *know* how to build build-system
executables, like gen*.exe.  Why can't we have small C programs that
know where as/ld are, know how to exec them portably (libiberty), etc?
That gives us the functionality of symlinks even on platforms like
MinGW that support neither symlinks nor shell scripts, without the
nasty side effects of using cp or symlinks.

Heck, it can even search $PATH for us.

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

[Daniel Jacobowitz]

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

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

[Daniel Jacobowitz]

On Wed, Jul 20, 2005 at 10:58:05PM -0400, DJ Delorie wrote:
> 
> > Is that actually true, though?  Doesn't GNU ld try to locate files
> > relative to its invoked path?
> 
> Sometimes, for sysroots and ldscripts.  I wouldn't expect MinGW (or
> any native linker) to use this feature.  GCC usually passes ld
> whatever path specifications it needs.

I build mingw cross toolchains with sysroots :-)  That'll be affected
by this change.  Of course, currently I cross-build them from
--build=i686-linux, so it doesn't affect me directly.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

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

[Christopher Faylor]

On Wed, Jul 20, 2005 at 10:58:05PM -0400, DJ Delorie wrote:
>> Is that actually true, though?  Doesn't GNU ld try to locate files
>> relative to its invoked path?
>
>Sometimes, for sysroots and ldscripts.  I wouldn't expect MinGW (or
>any native linker) to use this feature.  GCC usually passes ld
>whatever path specifications it needs.

Wouldn't that mean that 'cp' is a valid fallback even for non-GNU lds?

>> 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?
>
>A thought occurs to me... we *know* how to build build-system
>executables, like gen*.exe.  Why can't we have small C programs that
>know where as/ld are, know how to exec them portably (libiberty), etc?
>That gives us the functionality of symlinks even on platforms like
>MinGW that support neither symlinks nor shell scripts, without the
>nasty side effects of using cp or symlinks.
>
>Heck, it can even search $PATH for us.

That sounds like a good idea to me.

cgf

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

[Christopher Faylor]

On Wed, Jul 20, 2005 at 11:10:49PM -0400, DJ Delorie wrote:
>>Wouldn't that mean that 'cp' is a valid fallback even for non-GNU lds?
>
>We don't know what *else* a non-gnu linker/assembler might need.

I guess what I'm trying to get at here is some feeling for whether the
shell script method is there to work around a known problem or if it
is just working around a potential problem which might occur on some
theoretical platform which insists that its ld must be run from a
specific location.

But I guess it's no more than idle curiousity.

cgf

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

[DJ Delorie]

> I build mingw cross toolchains with sysroots :-) That'll be affected
> by this change.  Of course, currently I cross-build them from
> --build=i686-linux, so it doesn't affect me directly.

The problem case is build=mingw, not host=mingw.  I suppose a
mingw-hosted (and -built) cross compiler might be a problem.

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

[DJ Delorie]

> Wouldn't that mean that 'cp' is a valid fallback even for non-GNU lds?

We don't know what *else* a non-gnu linker/assembler might need.

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

[Paolo Bonzini]

>>Heck, it can even search $PATH for us.
> 
> That sounds like a good idea to me.

Please assign the bug to me.  I am not receiving Bugzilla mail for some 
reason, I guess I'll have to subscribe to gcc-bugs and use procmail.

Paolo

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

[François-Xavier Coudert]

Coming back to this topic.

Nobody has answered to one of my questions: if the mingw/cygwin
maintainers can't approve such a patch, who can?

FX

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

[Christopher Faylor]

On Mon, Jul 25, 2005 at 03:37:55PM +0200, Fran?ois-Xavier Coudert wrote:
>Coming back to this topic.
>
>Nobody has answered to one of my questions: if the mingw/cygwin
>maintainers can't approve such a patch, who can?

Presumably, people with blanket write privs and people responsible for
the build machinery.

cgf

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

[DJ Delorie]

> Presumably, people with blanket write privs and people responsible for
> the build machinery.

Yup, that's them.

I did a little historical digging on this item, and the original
trigger was http://gcc.gnu.org/ml/gcc-patches/2005-05/msg00280.html
where Paolo needed to switch from symlinks to hardlinks for toplevel
bootstrapping.  So, I think we've confused the issue enough that we
may be making bad decisions (or at least *I* am confused and may make
bad decisions ;).

Paolo, could you go back and think about the bootstrapping problem
from MinGW's perspective?

Danny, could you summarize which build features MinGW supports?  (I
assume cp and $(SHELL) but not symlinks, hardlinks, or #!).  DJGPP and
Cygwin shouldn't be a problem here; they both support symlinks and #!
but I don't think they support hardlinks.

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

[Christopher Faylor]

On Mon, Jul 25, 2005 at 04:48:45PM -0400, DJ Delorie wrote:
>> Presumably, people with blanket write privs and people responsible for
>> the build machinery.
>
>Yup, that's them.
>
>I did a little historical digging on this item, and the original
>trigger was http://gcc.gnu.org/ml/gcc-patches/2005-05/msg00280.html
>where Paolo needed to switch from symlinks to hardlinks for toplevel
>bootstrapping.  So, I think we've confused the issue enough that we
>may be making bad decisions (or at least *I* am confused and may make
>bad decisions ;).
>
>Paolo, could you go back and think about the bootstrapping problem
>from MinGW's perspective?
>
>Danny, could you summarize which build features MinGW supports?  (I
>assume cp and $(SHELL) but not symlinks, hardlinks, or #!).  DJGPP and
>Cygwin shouldn't be a problem here; they both support symlinks and #!
>but I don't think they support hardlinks.

For shell commands, the MSys build environment supports pretty much
everything that Cygwin does, which would be everything currently in that
makefile rule.  The problem is that when gcc executes, it uses
(eventually) the unadulterated Windows CreateProcess call which does not
understand cygwin/MSys symlinks or '#!' shell scripts or any other type
of shell script.  It would understand a .bat or .cmd file, but adding
.bat or .cmd file processing to Makefile.in is probably not something
that we want to do.

Hard links would be supported by everything since Windows understands
hard links at the OS level and Cygwin/MSys can create them (in some
cases).  They aren't a generic solution, however, as the makefile rule
demonstrates.

Maybe one solution would be to patch pex-win32 for mingw so that it
could understand '#!' style shell scripts?  That would at least allow
bootstrapping.  It wouldn't be useful generic pure-windows installation,
but presumably a user wouldn't have to worry about that because
everything would be installed correctly.

cgf

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

[DJ Delorie]

> Maybe one solution would be to patch pex-win32 for mingw so that it
> could understand '#!' style shell scripts?  That would at least
> allow bootstrapping.

That would be wonderful, and that's exactly the right place to put it
too.  I'm assuming I can persuade one of you to do that?  ;-)

I'm going to define pex-win32.c as being within the realm of the mingw
maintainership (if you hadn't assumed that already).

> It wouldn't be useful generic pure-windows installation,

It would still be *available* though, so you could (for example) wrap
your assembler in a shell script for debugging purposes, and gcc could
still run it.

Plus binutils uses it (windres, dlltool), so same minor benefit there.

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

[Christopher Faylor]

On Mon, Jul 25, 2005 at 05:23:54PM -0400, DJ Delorie wrote:
>>Maybe one solution would be to patch pex-win32 for mingw so that it
>>could understand '#!' style shell scripts?  That would at least allow
>>bootstrapping.
>
>That would be wonderful, and that's exactly the right place to put it
>too.  I'm assuming I can persuade one of you to do that?  ;-)
>
>I'm going to define pex-win32.c as being within the realm of the mingw
>maintainership (if you hadn't assumed that already).

I'd be happy to implement this.  I'd like to get Danny's opinion on this
first, though, in case I missed something.

cgf

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

[Danny Smith]

 From: Christopher Faylor
 Sent: Tuesday, July 26, 2005 9:33 AM
> 
> On Mon, Jul 25, 2005 at 05:23:54PM -0400, DJ Delorie wrote:
> >>Maybe one solution would be to patch pex-win32 for mingw so that it 
> >>could understand '#!' style shell scripts?  That would at 
> least allow 
> >>bootstrapping.
> >
> >That would be wonderful, and that's exactly the right place 
> to put it 
> >too.  I'm assuming I can persuade one of you to do that?  ;-)
> >
> >I'm going to define pex-win32.c as being within the realm of 
> the mingw 
> >maintainership (if you hadn't assumed that already).
> 
> I'd be happy to implement this.  I'd like to get Danny's 
> opinion on this first, though, in case I missed something.

Thanks Chris,  
I don't see any obvious problems. yet.
Danny
> 
> cgf
> 

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

[Paolo Bonzini]

>Paolo, could you go back and think about the bootstrapping problem
>from MinGW's perspective?
>  
>
I had considered cygwin, that had some problems because of the 
executable-file extension.  I had also thought of using batch files via 
config.build, but got stuck because Windows. does not have as far as I 
know, the equivalent of "$@"; and anyway it seems strange to need a 
batch file where everything else is msys-based.  So yes, I think the 
solution of hacking pex-win32.c is great.

Paolo

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

[Christopher Faylor]

On Mon, Jul 25, 2005 at 05:33:19PM -0400, Christopher Faylor wrote:
>On Mon, Jul 25, 2005 at 05:23:54PM -0400, DJ Delorie wrote:
>>>Maybe one solution would be to patch pex-win32 for mingw so that it
>>>could understand '#!' style shell scripts?  That would at least allow
>>>bootstrapping.
>>
>>That would be wonderful, and that's exactly the right place to put it
>>too.  I'm assuming I can persuade one of you to do that?  ;-)
>>
>>I'm going to define pex-win32.c as being within the realm of the mingw
>>maintainership (if you hadn't assumed that already).
>
>I'd be happy to implement this.  I'd like to get Danny's opinion on this
>first, though, in case I missed something.

With DJ's (private) approval, I've checked in a fix to implement this.
Sorry for the long delay.

cgf

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

[Mark Mitchell]

Ross Ridge wrote:

>>Right.  The real solution is to separate libgcc from the rest of the 
>>compiler; you should be able to (a) use configure to detect features of 
>>your as/ld, (b) build the compiler, (c) install it, and, only then, (d) 
>>start building libraries.
> 
> 
> Sorry, but I don't see the relevence of this either.  Are you and DJ
> Delorie trying to address some other problem then the fact that GCC
> doesn't bootstrap on MinGW builds?

Well, neither of us is addressing that directly.  However, I'm 
addressing the root cause of the problem -- namely, that we try to run 
the compiler out of the build directory, which causes all manner of 
complication.

-- 
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com
(916) 791-8304

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

[Ross Ridge]

Ross Ridge wrote:
>I don't see how the existance of configure changes the fact the GCC
>compiler driver exists,

DJ Delorie wrote:
>At the time you're running configure, the gcc driver does *not* exist,
>but you *do* need to run as and ld to test what features they support,
>information which is needed in order to *build* gcc.

Ross Ridge wrote:
> I don't see the relevence to problem at hand.  The Makefile that contains
> the currect hack that's causing the problem doesn't exist at configure
> time either.

Mark Mitchell wrote:
> Right.  The real solution is to separate libgcc from the rest of the 
> compiler; you should be able to (a) use configure to detect features of 
> your as/ld, (b) build the compiler, (c) install it, and, only then, (d) 
> start building libraries.

Sorry, but I don't see the relevence of this either.  Are you and DJ
Delorie trying to address some other problem then the fact that GCC
doesn't bootstrap on MinGW builds?

						Ross Ridge

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

[Mark Mitchell]

Ross Ridge wrote:
> Ross Ridge wrote:
> 
>>I don't see how the existance of configure changes the fact the GCC
>>compiler driver exists,
> 
>  
> DJ Delorie wrote:
> 
>>At the time you're running configure, the gcc driver does *not* exist,
>>but you *do* need to run as and ld to test what features they support,
>>information which is needed in order to *build* gcc.
> 
> 
> I don't see the relevence to problem at hand.  The Makefile that contains
> the currect hack that's causing the problem doesn't exist at configure
> time either.

Right.  The real solution is to separate libgcc from the rest of the 
compiler; you should be able to (a) use configure to detect features of 
your as/ld, (b) build the compiler, (c) install it, and, only then, (d) 
start building libraries.

-- 
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com
(916) 791-8304

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

[Ross Ridge]

Ross Ridge wrote:
> I don't see how the existance of configure changes the fact the GCC
> compiler driver exists,
 
DJ Delorie wrote:
> At the time you're running configure, the gcc driver does *not* exist,
> but you *do* need to run as and ld to test what features they support,
> information which is needed in order to *build* gcc.

I don't see the relevence to problem at hand.  The Makefile that contains
the currect hack that's causing the problem doesn't exist at configure
time either.  If your proposed solution of creating new programs to
execute as and ld were implemented then these new programs would also
not exist at configure time.  It's not a problem in configure that's
causing the bootstrap failure, it's a bug in the Makefile.

						Ross Ridge

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

[DJ Delorie]

> I don't see how the existance of configure changes the fact the GCC
> compiler driver exists,

At the time you're running configure, the gcc driver does *not* exist,
but you *do* need to run as and ld to test what features they support,
information which is needed in order to *build* gcc.

It's a chicken and egg type problem.

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

[Ross Ridge]

Ross Ridge wrote:
> You already have a not-so-small C program that's supposed to know
> where as and ld are.

DJ Delorie wrote:
> You're forgetting about configure.

I don't see how the existance of configure changes the fact the GCC
compiler driver exists, is capable of running and as and ld, and is
supposed to know where they are.  It even does PATH-like searches.
Why not just fix it so it runs the correct version of as and ld directly
during the bootstrap process?  Add an a "--use-bootstrap-binutils" flag
or a "--with-ld=<file>" flag to the compiler driver, that way the newly
built compiler driver can directly execute the version of ld and as the
current makefile hack is trying to force it into running.

						Ross Ridge

-- 
 l/  //	  Ross Ridge -- The Great HTMU
[oo][oo]  rridge@csclub.uwaterloo.ca
-()-/()/  http://www.csclub.uwaterloo.ca/u/rridge/ 
 db  //	  

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

[DJ Delorie]

> You already have a not-so-small C program that's supposed to know
> where as and ld are.

You're forgetting about configure.

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

[Ross Ridge]

>A thought occurs to me... we *know* how to build build-system
>executables, like gen*.exe.  Why can't we have small C programs that
>know where as/ld are, know how to exec them portably (libiberty), etc?

You already have a not-so-small C program that's supposed to know where
as and ld are.  Unfortunately, it seems to get this wrong is some case
or another and thus these rules for "linking" the utilities into the
build directory were added.  Maybe it's the gcc front end that needed
to be fixed, not the makefile.

						Ross Ridge

-- 
 l/  //	  Ross Ridge -- The Great HTMU
[oo][oo]  rridge@csclub.uwaterloo.ca
-()-/()/  http://www.csclub.uwaterloo.ca/u/rridge/ 
 db  //