[patch] Fix i386-mingw32 build failure

[patch] Fix i386-mingw32 build failure

[FX Coudert]

[-- Attachment #1: Type: text/plain, Size: 848 bytes --]

PING ** 2

Attached patch fixes PR bootstrap/22259 (right now, a simple ./configure 
&& make build fails on i386-mingw32). It creates a special case for 
in-tree as, collect-ld and nm scripts: since mingw32 cannot spawn shell 
scripts, it copies $(ORIGINAL_AS_FOR_TARGET), $(ORIGINAL_LD_FOR_TARGET) 
and $(ORIGINAL_NM_FOR_TARGET) in the tree.

There has been discussion on whether this is the best way to do things
(see thread from 
http://gcc.gnu.org/ml/gcc-patches/2005-07/msg01193.html), but nobody 
suggested another patch that actually makes build possible on 
i386-mingw32. And, from what I have understood, none of the mingw 
maintainers have anything against the patch, but they can't approve it.

Can someone with approval privilege over the build system look at this, 
and OK it? (it's a very simple patch)

Thanks,
FX


:ADDPATCH build:

[-- Attachment #2: building.ChangeLog --]
[-- Type: text/plain, Size: 204 bytes --]

2005-08-06  Francois-Xavier Coudert  <coudert@clipper.ens.fr>

	PR bootstrap/22259
	* Makfile.in (stamp-as, stamp-collect-ld, stamp-nm): Add special
	case for mingw32 since it cannot spawn shell scripts.

[-- Attachment #3: building.diff --]
[-- Type: text/plain, Size: 2019 bytes --]

Index: gcc/Makefile.in
===================================================================
RCS file: /cvsroot/gcc/gcc/gcc/Makefile.in,v
retrieving revision 1.1534
diff -p -u -r1.1534 Makefile.in
--- gcc/Makefile.in	3 Aug 2005 14:18:34 -0000	1.1534
+++ gcc/Makefile.in	6 Aug 2005 11:29:02 -0000
@@ -1228,10 +1228,15 @@ stamp-as: $(ORIGINAL_AS_FOR_TARGET)
 	     echo $(LN) $< as$(exeext); \
 	     $(LN) $< as$(exeext) || cp $< as$(exeext) ;; \
 	  *) \
-	     rm -f as; \
-	     echo '#!$(SHELL)' > as; \
-	     echo 'exec $(ORIGINAL_AS_FOR_TARGET) "$$@"' >> as ; \
-	     chmod +x as ;; \
+	     rm -f as$(exeext); \
+	     case "$(build)" in \
+		*mingw32*) \
+		  cp $(ORIGINAL_AS_FOR_TARGET) as$(exeext) ;; \
+		*) \
+		  echo '#!$(SHELL)' > as; \
+		  echo 'exec $(ORIGINAL_AS_FOR_TARGET) "$$@"' >> as ; \
+		  chmod +x as ;; \
+	     esac \
 	esac
 	echo timestamp > $@
 
@@ -1245,9 +1250,14 @@ stamp-collect-ld: $(ORIGINAL_LD_FOR_TARG
 	     $(LN) $< collect-ld$(exeext) || cp $< collect-ld$(exeext) ;; \
 	  *) \
 	     rm -f collect-ld$(exeext); \
-	     echo '#!$(SHELL)' > collect-ld; \
-	     echo 'exec $(ORIGINAL_LD_FOR_TARGET) "$$@"' >> collect-ld ; \
-	     chmod +x collect-ld ;; \
+	     case "$(build)" in \
+		*mingw32*) \
+		  cp $(ORIGINAL_LD_FOR_TARGET) collect-ld$(exeext) ;; \
+		*) \
+		  echo '#!$(SHELL)' > collect-ld; \
+		  echo 'exec $(ORIGINAL_LD_FOR_TARGET) "$$@"' >> collect-ld ; \
+		  chmod +x collect-ld ;; \
+	     esac \
 	esac
 	echo timestamp > $@
 
@@ -1261,9 +1271,14 @@ stamp-nm: $(ORIGINAL_NM_FOR_TARGET)
 	     $(LN) $< nm$(exeext) || cp $< nm$(exeext) ;; \
 	  *) \
 	     rm -f nm$(exeext); \
-	     echo '#!$(SHELL)' > nm; \
-	     echo 'exec $(ORIGINAL_NM_FOR_TARGET) "$$@"' >> nm ; \
-	     chmod +x nm ;; \
+	     case "$(build)" in \
+		*mingw32*) \
+		  cp $(ORIGINAL_NM_FOR_TARGET) nm$(exeext) ;; \
+		*) \
+		  echo '#!$(SHELL)' > nm; \
+		  echo 'exec $(ORIGINAL_NM_FOR_TARGET) "$$@"' >> nm ; \
+		  chmod +x nm ;; \
+	     esac \
 	esac
 	echo timestamp > $@
 

Re: [patch] Fix i386-mingw32 build failure

[Christopher Faylor]

On Sat, Aug 06, 2005 at 01:37:44PM +0200, FX Coudert wrote:
>PING ** 2
>
>Attached patch fixes PR bootstrap/22259 (right now, a simple ./configure 
>&& make build fails on i386-mingw32). It creates a special case for 
>in-tree as, collect-ld and nm scripts: since mingw32 cannot spawn shell 
>scripts, it copies $(ORIGINAL_AS_FOR_TARGET), $(ORIGINAL_LD_FOR_TARGET) 
>and $(ORIGINAL_NM_FOR_TARGET) in the tree.
>
>There has been discussion on whether this is the best way to do things
>(see thread from 
>http://gcc.gnu.org/ml/gcc-patches/2005-07/msg01193.html), but nobody 
>suggested another patch that actually makes build possible on 
>i386-mingw32. And, from what I have understood, none of the mingw 
>maintainers have anything against the patch, but they can't approve it.
>
>Can someone with approval privilege over the build system look at this, 
>and OK it? (it's a very simple patch)

Did you read all of the discussion about this the last time this came
up?  The consensus seemed to be that this was not the way to fix the
problem.  I suggested that modifying pex-* functions to understand #!
scripts might be the best way to deal with this.

I will do this eventually, but if you want to take a crack at it,
please feel free.

cgf

Re: [patch] Fix i386-mingw32 build failure

[Paolo Bonzini]

[-- Attachment #1: Type: text/plain, Size: 497 bytes --]

> Can someone with approval privilege over the build system look at this, 
> and OK it? (it's a very simple patch)

I must apologize for the delay in handling this.  This alternative patch 
avoids that mingw is hardcoded in the makefiles.  FWIW, it is also even 
smaller,

  3 files changed, 19 insertions(+), 12 deletions(-)

vs.

  1 files changed, 25 insertions(+), 10 deletions(-)

:ADDPATCH build:

I have only tested it on Linux, can you give it a try?  Ok if FX's 
testing succeeds?

Paolo

[-- Attachment #2: pr22259.patch --]
[-- Type: text/plain, Size: 3898 bytes --]

2005-08-09  Paolo Bonzini  <bonzini@gnu.org>

	* config.build (build_have_sh_scripts): Default to yes,
	set to no for mingw32.
	* configure.ac (build_have_sh_scripts): AC_SUBST it.
	* Makefile.in (stamp-as, stamp-collect-ld, stamp-nm): If
	build_have_sh_scripts is false, rely on $(LN).
	* configure: Regenerate.

Index: config.build
===================================================================
RCS file: /cvs/gcc/gcc/gcc/config.build,v
retrieving revision 1.4
diff -p -u -r1.4 config.build
--- config.build	25 Jun 2005 01:59:35 -0000	1.4
+++ config.build	9 Aug 2005 07:25:42 -0000
@@ -42,12 +42,17 @@
 #
 #  build_exeext		Set to the suffix, if the build machine requires
 #			executables to have a file name suffix.
+#
+#  build_have_sh_scripts
+#                       Set to yes or no, depending on whether the built
+#                       compiler can run Bourne shell scripts.
 
 # Default settings.
 build_xm_file=
 build_xm_defines=
 build_exeext=
 build_install_headers_dir=install-headers-tar
+build_have_sh_scripts=yes
 
 # System-specific settings.
 case $build in
@@ -80,6 +85,7 @@ case $build in
   i[34567]86-*-mingw32*)
     build_xm_file=i386/xm-mingw32.h
     build_exeext=.exe
+    build_have_sh_scripts=no
     ;;
   i[34567]86-pc-msdosdjgpp*)
     build_xm_file=i386/xm-djgpp.h
Index: configure.ac
===================================================================
RCS file: /cvs/gcc/gcc/gcc/configure.ac,v
retrieving revision 2.125
diff -p -u -r2.125 configure.ac
--- configure.ac	29 Jul 2005 19:20:44 -0000	2.125
+++ configure.ac	9 Aug 2005 07:25:43 -0000
@@ -3335,6 +3335,7 @@ AC_SUBST(all_lang_makefiles)
 AC_SUBST(all_languages)
 AC_SUBST(all_stagestuff)
 AC_SUBST(build_exeext)
+AC_SUBST(build_have_sh_scripts)
 AC_SUBST(build_install_headers_dir)
 AC_SUBST(build_xm_file_list)
 AC_SUBST(build_xm_include_list)
Index: Makefile.in
===================================================================
RCS file: /cvs/gcc/gcc/gcc/Makefile.in,v
retrieving revision 1.1535
diff -p -u -r1.1535 Makefile.in
--- Makefile.in	6 Aug 2005 13:25:52 -0000	1.1535
+++ Makefile.in	9 Aug 2005 07:25:43 -0000
@@ -1221,13 +1221,13 @@ cpp$(exeext): gcc.o cppspec.o version.o 
 # (if it is a hard link).
 stamp-as: $(ORIGINAL_AS_FOR_TARGET)
 	@echo creating as; \
-	case "$(ORIGINAL_AS_FOR_TARGET)" in \
-	  ./as) ;; \
-	  ../*) \
+	case "$(ORIGINAL_AS_FOR_TARGET):@build_have_sh_scripts@" in \
+	  ./as:*) ;; \
+	  ../*:* | *:no) \
 	     rm -f as$(exeext); \
 	     echo $(LN) $< as$(exeext); \
 	     $(LN) $< as$(exeext) || cp $< as$(exeext) ;; \
-	  *) \
+	  *:yes) \
 	     rm -f as; \
 	     echo '#!$(SHELL)' > as; \
 	     echo 'exec $(ORIGINAL_AS_FOR_TARGET) "$$@"' >> as ; \
@@ -1237,13 +1237,13 @@ stamp-as: $(ORIGINAL_AS_FOR_TARGET)
 
 stamp-collect-ld: $(ORIGINAL_LD_FOR_TARGET)
 	@echo creating collect-ld; \
-	case "$(ORIGINAL_LD_FOR_TARGET)" in \
-	  ./collect-ld) ;; \
-	  ../*) \
+	case "$(ORIGINAL_LD_FOR_TARGET):@build_have_sh_scripts@" in \
+	  ./collect-ld:*) ;; \
+	  ../*:* | *:no) \
 	     rm -f collect-ld$(exeext); \
 	     echo $(LN) $< collect-ld$(exeext); \
 	     $(LN) $< collect-ld$(exeext) || cp $< collect-ld$(exeext) ;; \
-	  *) \
+	  *:yes) \
 	     rm -f collect-ld$(exeext); \
 	     echo '#!$(SHELL)' > collect-ld; \
 	     echo 'exec $(ORIGINAL_LD_FOR_TARGET) "$$@"' >> collect-ld ; \
@@ -1253,13 +1253,13 @@ stamp-collect-ld: $(ORIGINAL_LD_FOR_TARG
 
 stamp-nm: $(ORIGINAL_NM_FOR_TARGET)
 	@echo creating nm; \
-	case "$(ORIGINAL_NM_FOR_TARGET)" in \
-	  ./nm) ;; \
-	  ../*) \
+	case "$(ORIGINAL_NM_FOR_TARGET):@build_have_sh_scripts@" in \
+	  ./nm:*) ;; \
+	  ../*:* | *:no) \
 	     rm -f nm$(exeext); \
 	     echo $(LN) $< nm$(exeext); \
 	     $(LN) $< nm$(exeext) || cp $< nm$(exeext) ;; \
-	  *) \
+	  *:yes) \
 	     rm -f nm$(exeext); \
 	     echo '#!$(SHELL)' > nm; \
 	     echo 'exec $(ORIGINAL_NM_FOR_TARGET) "$$@"' >> nm ; \

Re: [patch] Fix i386-mingw32 build failure

[Christopher Faylor]

On Tue, Aug 09, 2005 at 09:33:19AM +0200, Paolo Bonzini wrote:
>>Can someone with approval privilege over the build system look at this, 
>>and OK it? (it's a very simple patch)
>
>I must apologize for the delay in handling this.  This alternative patch 
>avoids that mingw is hardcoded in the makefiles.  FWIW, it is also even 
>smaller,
>
> 3 files changed, 19 insertions(+), 12 deletions(-)
>
>vs.
>
> 1 files changed, 25 insertions(+), 10 deletions(-)
>
>:ADDPATCH build:
>
>I have only tested it on Linux, can you give it a try?  Ok if FX's 
>testing succeeds?
>
>2005-08-09  Paolo Bonzini  <bonzini@gnu.org>
>
>	* config.build (build_have_sh_scripts): Default to yes,
>	set to no for mingw32.
>	* configure.ac (build_have_sh_scripts): AC_SUBST it.
>	* Makefile.in (stamp-as, stamp-collect-ld, stamp-nm): If
>	build_have_sh_scripts is false, rely on $(LN).
>	* configure: Regenerate.

This would conflict with my proposed changes to pex-win32.c .  It seems
like getting '#!' functioning on mingw would be a better solution than
relying on $(LN) on mingw.

I haven't gotten around to implementing this in libiberty because I've
been on vacation but I should have time to do this this week, if it is
still desirable.

cgf

Re: [patch] Fix i386-mingw32 build failure

[FX Coudert]

> I have only tested it on Linux, can you give it a try?  Ok if FX's 
> testing succeeds?

Testing succeeded on i686-mingw32. Configures and builds fine.
Can someone review this patch?

FX

Re: [patch] Fix i386-mingw32 build failure

[Mark Mitchell]

Christopher Faylor wrote:

> This would conflict with my proposed changes to pex-win32.c .  It seems
> like getting '#!' functioning on mingw would be a better solution than
> relying on $(LN) on mingw.

FWIW, I'm opposed to the "#!" change to MinGW.  It just seems hackish to 
me, and it means that we'll pay an additional cost on all normal uses of 
pex-* on MinGW, even after the compiler is installed.

The correct solution to this is to install the assemblers and linkers 
before building the compiler, in places that the compiler expects to 
find them, on all systems, in all configurations, and then totally avoid 
the symlinks/copies/etc. out of the main tree.  I realize that people 
who do one-tree builds will object, but my answer to that is just that 
there should be an installation stage between building binutils and 
building gcc.

The even more correct solution is to not build anything with the 
compiler (including libgcc) until after it is installed.  Then, it will 
just look where it would normally look, and all will be well.

However, I also recognize that we need to do something before 4.1 to fix 
this problem and that we need something simple enough to be viable in 
that timeframe.  But, if Paolo can fix this without having to add #!, I 
think that would be great.

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

Re: [patch] Fix i386-mingw32 build failure

[Daniel Jacobowitz]

On Wed, Aug 10, 2005 at 10:05:26AM -0700, Mark Mitchell wrote:
> Christopher Faylor wrote:
> 
> >This would conflict with my proposed changes to pex-win32.c .  It seems
> >like getting '#!' functioning on mingw would be a better solution than
> >relying on $(LN) on mingw.
> 
> FWIW, I'm opposed to the "#!" change to MinGW.  It just seems hackish to 
> me, and it means that we'll pay an additional cost on all normal uses of 
> pex-* on MinGW, even after the compiler is installed.

Not if it's implemented after CreateProcess fails, we won't.  I don't
think your argument applies.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: [patch] Fix i386-mingw32 build failure

[Mark Mitchell]

Daniel Jacobowitz wrote:
> On Wed, Aug 10, 2005 at 10:05:26AM -0700, Mark Mitchell wrote:
> 
>>Christopher Faylor wrote:
>>
>>
>>>This would conflict with my proposed changes to pex-win32.c .  It seems
>>>like getting '#!' functioning on mingw would be a better solution than
>>>relying on $(LN) on mingw.
>>
>>FWIW, I'm opposed to the "#!" change to MinGW.  It just seems hackish to 
>>me, and it means that we'll pay an additional cost on all normal uses of 
>>pex-* on MinGW, even after the compiler is installed.
> 
> 
> Not if it's implemented after CreateProcess fails, we won't.  I don't
> think your argument applies.

Good point!

I still think it's a bad solution, though; it's imposing special 
semantics for process execution in libiberty, rather than the normal 
ones that you would expect from the OS.

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

Re: [patch] Fix i386-mingw32 build failure

[Christopher Faylor]

On Wed, Aug 10, 2005 at 10:38:26AM -0700, Mark Mitchell wrote:
>Daniel Jacobowitz wrote:
>>On Wed, Aug 10, 2005 at 10:05:26AM -0700, Mark Mitchell wrote:
>>
>>>Christopher Faylor wrote:
>>>
>>>
>>>>This would conflict with my proposed changes to pex-win32.c .  It seems
>>>>like getting '#!' functioning on mingw would be a better solution than
>>>>relying on $(LN) on mingw.
>>>
>>>FWIW, I'm opposed to the "#!" change to MinGW.  It just seems hackish to 
>>>me, and it means that we'll pay an additional cost on all normal uses of 
>>>pex-* on MinGW, even after the compiler is installed.
>>
>>
>>Not if it's implemented after CreateProcess fails, we won't.  I don't
>>think your argument applies.
>
>Good point!
>
>I still think it's a bad solution, though; it's imposing special 
>semantics for process execution in libiberty, rather than the normal 
>ones that you would expect from the OS.

Aren't the pex* functions designed to provide a uniform interface where
"uniform" means "like unix"?

cgf

Re: [patch] Fix i386-mingw32 build failure

[DJ Delorie]

> I still think it's a bad solution, though; it's imposing special
> semantics for process execution in libiberty, rather than the normal
> ones that you would expect from the OS.

Doing that is part of the purpose of libiberty.  If the OS does
something unusual, we try to make it act in a conforming way, so that
the rest of the tools need not worry about the OS differences.  Adding
support for #! scripts is one of the ways we can make MinGW more
conforming (Cygwin and DJGPP already support #!) to the norm.

Re: [patch] Fix i386-mingw32 build failure

[DJ Delorie]

> Aren't the pex* functions designed to provide a uniform interface
> where "uniform" means "like unix"?

Uniform, yes.  "Like Unix" is a coincidence, not a goal.  Sometimes we
hide a unix-specific feature because we can't mimic it elsewhere (like
simultaneous multithreading) but we prefer to add or wrap
functionality (like #! support).

Re: [patch] Fix i386-mingw32 build failure

[Mark Mitchell]

Christopher Faylor wrote:

> Aren't the pex* functions designed to provide a uniform interface where
> "uniform" means "like unix"?

I guess I'm not the right person to answer that...

I think they are designed to provide a uniform interface to process 
creation, etc. that is a lowest-common-denominator across systems. 
Running scripts seems to me outside of scope.  I certainly think that 
this is a topic on which people could reasonably disagree.

Part of my concern is that we seem to be adding to the complexity of our 
already baroque build process, in lieu of just attacking the problem 
head-on.  Even a new driver option for additional directories to search 
seems better to me.

However, by the time I write this, I see that DJ -- who is a right 
person to answer to talk about the purpose of libiberty -- thinks #! is 
a good idea.  So, consider me the loyal opposition; let's get on with 
the fix you and DJ like. :-)

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

Re: [patch] Fix i386-mingw32 build failure

[Joe Buck]

On Wed, Aug 10, 2005 at 02:35:41PM -0400, DJ Delorie wrote:
> 
> > I still think it's a bad solution, though; it's imposing special
> > semantics for process execution in libiberty, rather than the normal
> > ones that you would expect from the OS.
> 
> Doing that is part of the purpose of libiberty.  If the OS does
> something unusual, we try to make it act in a conforming way, so that
> the rest of the tools need not worry about the OS differences.  Adding
> support for #! scripts is one of the ways we can make MinGW more
> conforming (Cygwin and DJGPP already support #!) to the norm.

I'm inclined to agree that this seems like a natural use of libiberty;
the purpose all along has been to isolate OS differences, fill in missing
functions, etc.

Mark, can you think of any specific negative consequences?

Re: [patch] Fix i386-mingw32 build failure

[DJ Delorie]

> I think they are designed to provide a uniform interface to process 
> creation, etc. that is a lowest-common-denominator across systems. 

I think a better term is "highest common denominator".  We *do* want
to enhance systems when we can, because that makes it easier for the
application developers.  It's only the cases where we *can't* enhance
a system that we have to limit everyone else.

In the case of #!, since *all* process creation goes through
libiberty, it's trivially easy to have libiberty look for the #! and
support it on *any* platform that doesn't already support it.  Why
make app developers suffer without shell scripts when it's easy to
make them globally supported?

> Part of my concern is that we seem to be adding to the complexity of
> our already baroque build process, in lieu of just attacking the
> problem head-on.

Well, if everyone supports shell scripts, that's less configury and
Makefile madness outside of libiberty.

> Even a new driver option for additional directories to search seems
> better to me.

Supporting #! in libiberty doesn't have to stop you from enhancing gcc
anyway ;-)

Re: [patch] Fix i386-mingw32 build failure

[Christopher Faylor]

On Wed, Aug 10, 2005 at 11:41:30AM -0700, Mark Mitchell wrote:
>However, by the time I write this, I see that DJ -- who is a right
>person to answer to talk about the purpose of libiberty -- thinks #! is
>a good idea.  So, consider me the loyal opposition; let's get on with
>the fix you and DJ like.  :-)

Not to beat a dead horse, but this was all decided two weeks ago between
DJ as the libiberty/configury maintainer and Danny Smith and I as the
windows maintainers.  So, I would submit that the right people had
already made the decision.  I wouldn't have volunteered to make a change
to libiberty without DJ's blessing of the idea.

I'm building a compiler now to check out my changes.

cgf

Re: [patch] Fix i386-mingw32 build failure

[Marcin Dalecki]

On 2005-08-10, at 19:05, Mark Mitchell wrote:
>
> The even more correct solution is to not build anything with the  
> compiler (including libgcc) until after it is installed.  Then, it  
> will just look where it would normally look, and all will be well.

install host != build host

Most of the time if you do deilver software...

You just don't want the fresh instalation to involve trashing a  
working tool chain too.

> However, I also recognize that we need to do something before 4.1  
> to fix this problem and that we need something simple enough to be  
> viable in that timeframe.  But, if Paolo can fix this without  
> having to add #!, I think that would be great.

Re: [patch] Fix i386-mingw32 build failure

[Andreas Schwab]

Mark Mitchell <mark@codesourcery.com> writes:

> The even more correct solution is to not build anything with the 
> compiler (including libgcc) until after it is installed.  Then, it will 
> just look where it would normally look, and all will be well.

You sure don't want to overwrite a compiler that is known to work with a
compiler that is incomplete, never tested, and perhaps completely broken.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: [patch] Fix i386-mingw32 build failure

[Mark Mitchell]

Marcin Dalecki wrote:
> 
> On 2005-08-10, at 19:05, Mark Mitchell wrote:
> 
>>
>> The even more correct solution is to not build anything with the  
>> compiler (including libgcc) until after it is installed.  Then, it  
>> will just look where it would normally look, and all will be well.
> 
> 
> install host != build host
> 
> Most of the time if you do deilver software...
> 
> You just don't want the fresh instalation to involve trashing a  working 
> tool chain too.

I'm not sure what your point is -- but I'm quite familiar with building 
cross and Canadian cross toolchains.  If the GCC you're building can't 
run on the host system, then the whole discussion doesn't matter; you're 
not going to run the GCC in the build directory, in which case the 
symlinks we're talking about don't matter.

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

Re: [patch] Fix i386-mingw32 build failure

[Mark Mitchell]

Andreas Schwab wrote:
> Mark Mitchell <mark@codesourcery.com> writes:
> 
> 
>>The even more correct solution is to not build anything with the 
>>compiler (including libgcc) until after it is installed.  Then, it will 
>>just look where it would normally look, and all will be well.
> 
> 
> You sure don't want to overwrite a compiler that is known to work with a
> compiler that is incomplete, never tested, and perhaps completely broken.

I certainly didn't mean to suggest that -- but that doesn't mean you 
can't install the compiler somewhere.  That's part of why people have 
worked hard to make it relocatable.  We've had this entire discussion 
before, and as far as I can tell, there's agreement-in-principle: you 
build things, install them in a staging area, and then copy/reinstall 
into a final location when you're done.  That avoids all the complicated 
symlinks/-B/-L/-I options -- which are not only complex, but also have 
been known to mask problems in the installed compiler.  (Things work at 
build time, but not at install time.)

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

Re: [patch] Fix i386-mingw32 build failure

[Andreas Schwab]

Mark Mitchell <mark@codesourcery.com> writes:

> We've had this entire discussion before, and as far as I can tell,
> there's agreement-in-principle: you build things, install them in a
> staging area, and then copy/reinstall into a final location when you're
> done.

Sorry, I didn't think of that.  Now it makes perfectly sense.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: [patch] Fix i386-mingw32 build failure

[Ross Ridge]

> I am nearly ready to commit this patch but I went overboard and had it
> search in mingw and MSYS locations for the program to run (i.e.,
> "/bin/sh").

Since there's no MinGW shell, there's no point in looking in there.

  Then it occurred to me that maybe this was a little too
> "product specific" for something like libiberty.
> 
> Or should I yank out that code and just search for "sh" along the path?

If a PATH search doesn't turn up the shell then a desperate search
through the registery isn't likely to turn up right shell.  While in
other contexts finding any shell might be better than nothing, in this
context, fixing the MinGW build failure, the shell needs to be from the
same "Unix emulation" environment that running the build process.

						Ross Ridge

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

Re: [patch] Fix i386-mingw32 build failure

[Christopher Faylor]

On Thu, Aug 25, 2005 at 04:00:53PM -0400, DJ Delorie wrote:
>> So, should it default to finding an executable on the path first and
>> then look for MinGW/MSYS versions of the program if it can't find
>> the executable on the path?
>
>Hmmm... 99% of the cases will be "#!/bin/sh" anyway.  What's the
>"right" shell to run for that in MinGW?  If you can detect MinGW[*],
>and check the right MinGW places first, that's probably the best
>solution.
>
>[*] I'm thinking of an #ifdef in libiberty, nothing fancy.

The problem is that there's MinGW and there's MSYS.  MSYS is a Cygwin
fork that many MinGW people use as a build environment.  I can detect
that the compiler is a MinGW compiler but I can't necessarily detect, at
compile time, that MSYS is being used.  I can detect this at runtime,
though, but that means building in MSYS awareness iff pex-win32.o is
being built for MinGW.  I guess that can't really hurt.

cgf

Re: [patch] Fix i386-mingw32 build failure

[Christopher Faylor]

On Thu, Aug 25, 2005 at 02:59:24PM -0400, DJ Delorie wrote:
>pex-win32 is used by both MinGW and generic "winnt" targets, so I'd
>say keeping it generic is preferred, but if MinGW can be detected, add
>those checks too.

So, should it default to finding an executable on the path first and
then look for MinGW/MSYS versions of the program if it can't find
the executable on the path?

cgf

Re: [patch] Fix i386-mingw32 build failure

[DJ Delorie]

> So, should it default to finding an executable on the path first and
> then look for MinGW/MSYS versions of the program if it can't find
> the executable on the path?

Hmmm... 99% of the cases will be "#!/bin/sh" anyway.  What's the
"right" shell to run for that in MinGW?  If you can detect MinGW[*],
and check the right MinGW places first, that's probably the best
solution.

[*] I'm thinking of an #ifdef in libiberty, nothing fancy.

Re: [patch] Fix i386-mingw32 build failure

[DJ Delorie]

pex-win32 is used by both MinGW and generic "winnt" targets, so I'd
say keeping it generic is preferred, but if MinGW can be detected, add
those checks too.

Using WindowsRoutinesForQueryingStuff is fine; that file is already
Win32 specific.  Just don't break the mscdll stuff ;-)

Re: [patch] Fix i386-mingw32 build failure

[Christopher Faylor]

On Thu, Aug 11, 2005 at 02:20:04PM -0400, Christopher Faylor wrote:
>On Wed, Aug 10, 2005 at 05:30:03PM -0400, DJ Delorie wrote:
>>> Well, it's stopping a real fix for the MinGW build failure being made.
>>> Adding #! support to libiberty won't work because the problem scripts
>>> have MSYS/Cygwin paths for the shell (eg. "/bin/sh") that aren't likely
>>> to be valid to plain Windows.
>>
>>DJGPP solves this thusly:
>>
>>  /* If INTERP is a Unix-style pathname, like "/bin/sh", we will try
>>     it with the usual extensions and, if that fails, will further
>>     search for the basename of the shell along the PATH; this
>>     allows to run Unix shell scripts without editing their first line.  */
>
>That was the technique I am in the process of using, too.
>
>Hmm.  You know, I probably should just steal the code from DJGPP...

I am nearly ready to commit this patch but I went overboard and had it
search in mingw and MSYS locations for the program to run (i.e.,
"/bin/sh").  Then it occurred to me that maybe this was a little too
"product specific" for something like libiberty.

So, the question is, should pex-win32.c encapsulate specific knowledge
about MinGW and MSYS?  Or should I yank out that code and just search
for "sh" along the path?

FWIW, finding the appropriate directories for MinGW and MSYS requires
using a few of WindowsRoutinesForQueryingStuff.

cgf

Re: [patch] Fix i386-mingw32 build failure

[DJ Delorie]

> Hmm.  You know, I probably should just steal the code from DJGPP...

You could, if you feel like weeding out all the DPMI calls and dos-isms ;-)

It's in DJGPP's src/libc/dos/process/dosexec.c.  Search for
"script_exec".

Re: [patch] Fix i386-mingw32 build failure

[Christopher Faylor]

On Wed, Aug 10, 2005 at 05:30:03PM -0400, DJ Delorie wrote:
>> Well, it's stopping a real fix for the MinGW build failure being made.
>> Adding #! support to libiberty won't work because the problem scripts
>> have MSYS/Cygwin paths for the shell (eg. "/bin/sh") that aren't likely
>> to be valid to plain Windows.
>
>DJGPP solves this thusly:
>
>  /* If INTERP is a Unix-style pathname, like "/bin/sh", we will try
>     it with the usual extensions and, if that fails, will further
>     search for the basename of the shell along the PATH; this
>     allows to run Unix shell scripts without editing their first line.  */

That was the technique I am in the process of using, too.

Hmm.  You know, I probably should just steal the code from DJGPP...

cgf

Re: [patch] Fix i386-mingw32 build failure

[Ross Ridge]

> DJGPP solves this thusly:
> 
>   /* If INTERP is a Unix-style pathname, like "/bin/sh", we will try
>      it with the usual extensions and, if that fails, will further
>      search for the basename of the shell along the PATH; this
>      allows to run Unix shell scripts without editing their first line.  */
 
It's likely to work in this case, but it doesn't guarantee that the
shell that gets executed uses the same MSYS/Cygwin enviroment as the
rest of the build process.

						Ross Ridge

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

Re: [patch] Fix i386-mingw32 build failure

[DJ Delorie]

> Well, it's stopping a real fix for the MinGW build failure being made.
> Adding #! support to libiberty won't work because the problem scripts
> have MSYS/Cygwin paths for the shell (eg. "/bin/sh") that aren't likely
> to be valid to plain Windows.

DJGPP solves this thusly:

  /* If INTERP is a Unix-style pathname, like "/bin/sh", we will try
     it with the usual extensions and, if that fails, will further
     search for the basename of the shell along the PATH; this
     allows to run Unix shell scripts without editing their first line.  */

Re: [patch] Fix i386-mingw32 build failure

[Ross Ridge]

DJ Delorie wrote:
>Supporting #! in libiberty doesn't have to stop you from enhancing gcc
>anyway ;-)

Well, it's stopping a real fix for the MinGW build failure being made.
Adding #! support to libiberty won't work because the problem scripts
have MSYS/Cygwin paths for the shell (eg. "/bin/sh") that aren't likely
to be valid to plain Windows.

						Ross Ridge

Re: [patch] Fix i386-mingw32 build failure

[Paolo Bonzini]

> The consensus also seemed to be that it was just an aspect of a larger
> problem that no good solution had been proposed to solve yet.

I am working on a fix that is the same as FX's, but does not pollute the 
makefile with host triplets.  I am not a maintainer, but this was my 
primary objection to his patch.

Paolo

Re: [patch] Fix i386-mingw32 build failure

[Ross Ridge]

Christopher Faylor wrote:
>The consensus seemed to be that this was not the way to fix the problem.

The consensus also seemed to be that it was just an aspect of a larger
problem that no good solution had been proposed to solve yet.

>I suggested that modifying pex-* functions to understand #! scripts
>might be the best way to deal with this.

It seems to be a rather convoluted and complicated way of tricking the
newly built compiler driver to run a specific version of a program.
Especially since the #! hack currently used in the Makefile might get
replaced by some other hack.

						Ross Ridge