Christopher Faylor wrote:
> However, it could easily be standard. I could include a i686-pc-mingw32-gcc
> and a i686-pc-mingw-ld in the gcc distribution. And, I could also alias
> all of the i686-pc-cygwin-* tools to i686-pc-mingw32-*. That would provide
> the equivalent of a cross compilation
However, it could easily be standard.
I know, but we've been thru this before. This is just as big a PITA as
-mno-cygwin. (OTOH, it's a PITA for *you*, but causes *me* no
pain...Hmmm, I like it. )
I could include a
i686-pc-mingw32-gcc
and a i686-pc-mingw-ld in the gcc distribution. And
Christopher Faylor writes:
>
> On Tue, Feb 18, 2003 at 09:26:12PM -0500, Charles Wilson wrote:
> >You can work around this with wrapper scripts (e.g. 'mgcc' contains
> >'exec gcc -mno-cygwin $*') but that's non standard.
>
> However, it could easily be standard. I could include a
> i686-pc-min
On Tue, Feb 18, 2003 at 09:26:12PM -0500, Charles Wilson wrote:
>You can work around this with wrapper scripts (e.g. 'mgcc' contains
>'exec gcc -mno-cygwin $*') but that's non standard.
However, it could easily be standard. I could include a i686-pc-mingw32-gcc
and a i686-pc-mingw-ld in the gcc
Max Bowsher wrote:
But it does, 99.9% of the time, and I'm very reluctant to install a second
POSIX emulator, when Cygwin works very nicely.
On cygwin, uname says "cygwin"; it doesn't say "mingw". *By default* the
compiler -- without extra flags -- generates an executable that uses
cygwin. U
Charles Wilson wrote:
> Max Bowsher wrote:
>
>> I've discovered something which is only a problem when doing a
>> CC='gcc -mno-cygwin' compile - namely, that the new wrapper
>> executables do execv("/bin/bash",...), which quite obviously, msvcrt
>> doesn't understand.
>
> cygwin-target(or mingw-tar
Max Bowsher wrote:
Max, if you have time, could you build a 'release' setup + included
libs (libgetopt + gzip + bzip2) with the new libtool? I'd really
appreciate
that.
Yep, works fine.
thanks, Max.
--chuck
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting
Max Bowsher wrote:
I've discovered something which is only a problem when doing a
CC='gcc -mno-cygwin' compile - namely, that the new wrapper executables do
execv("/bin/bash",...), which quite obviously, msvcrt doesn't understand.
cygwin-target(or mingw-target) libtool does not work at all unle
Robert Collins wrote:
> On Wed, 2003-02-19 at 08:47, Max Bowsher wrote:
>
>
>> I've discovered something which is only a problem when doing a
>> CC='gcc -mno-cygwin' compile - namely, that the new wrapper
>> executables do execv("/bin/bash",...), which quite obviously, msvcrt
>> doesn't understan
On Wed, 2003-02-19 at 08:47, Max Bowsher wrote:
> I've discovered something which is only a problem when doing a
> CC='gcc -mno-cygwin' compile - namely, that the new wrapper executables do
> execv("/bin/bash",...), which quite obviously, msvcrt doesn't understand.
>
> Now, I don't think that ma
Charles Wilson wrote:
> I've updated libtool-devel to the 20030216 CVS, plus a rewritten
> win32_libid() function that should speed up linking libraries that
> have many dependencies.
>
> So, test and enjoy; I will probably make this the official cygwin
> libtool-devel very soon. Unless there are
I've updated libtool-devel to the 20030216 CVS, plus a rewritten
win32_libid() function that should speed up linking libraries that have
many dependencies.
So, test and enjoy; I will probably make this the official cygwin
libtool-devel very soon. Unless there are significant bugs reported, I
12 matches
Mail list logo
