Re: PING [4.1 regression, patch] build i686-pc-mingw32
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
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
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
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
> 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
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
> 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
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
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
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 [EMAIL PROTECTED] (916) 791-8304
Re: PING [4.1 regression, patch] build i686-pc-mingw32
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
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 [EMAIL PROTECTED] (916) 791-8304
Re: PING [4.1 regression, patch] build i686-pc-mingw32
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
> 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 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=" 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] [EMAIL PROTECTED] -()-/()/ http://www.csclub.uwaterloo.ca/u/rridge/ db //
Re: PING [4.1 regression, patch] build i686-pc-mingw32
> 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
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
>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] [EMAIL PROTECTED] -()-/()/ http://www.csclub.uwaterloo.ca/u/rridge/ db //
Re: PING [4.1 regression, patch] build i686-pc-mingw32
> 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
> 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
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
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
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
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
> 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
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
> 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
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
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
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
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
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
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
