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.
>>
>>Tha
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 f
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
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.
> 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 g
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-
> 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 har
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
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
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 releven
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 ne
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,
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
> 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
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
> You already have a not-so-small C program that's supposed to know
> where as and ld are.
You're forgetting about configure.
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
>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. Unfor
> 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 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 mig
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 the
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
>
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 pas
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 con
> 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 ming
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
> 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
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 abov
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
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 wer
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 alrea
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
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
33 matches
Mail list logo
