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