> 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 specif
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
> 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 MinG
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
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 ;-)
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
> 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".
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
Mark Mitchell <[EMAIL PROTECTED]> 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. No
> 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 f
Andreas Schwab wrote:
Mark Mitchell <[EMAIL PROTECTED]> 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 over
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 != bui
Mark Mitchell <[EMAIL PROTECTED]> 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
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
> 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
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") th
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
> 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 develo
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 libibert
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-denomin
> 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
> 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 conform
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 '#!' functio
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,
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
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
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
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 makef
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 inserti
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 t
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 #! scr
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
>script
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)
33 matches
Mail list logo
