- how to include gcc/mingw options when needed for python setup.py
situations
The Cygwin-hosted MinGW compilers are set up in a very similar way to cross-
compilation from Linux. Python and most of its infrastructure for building
C extensions do not support MinGW very well, from any host environ
Greetings, Matt Thomas!
> I need to find references describing methods to configure:
> - Cygwin gcc environment
> - the Cygwin version of MingGW environment
> - gcc or mingw configurations for python compilations
> My questions are:
> - how to include all needed gcc source paths (of many)
> - how
Thanks, this was pretty much exactly what I was looking for, but it turned
out the builds at gnuarm.org are so outdated that the option does not exist
(-fdebug-prefix-map=/cygdrive/c/=C:/ resulted in an error at least).
I managed to create a really dirty workaround for now which was to create
On Tue, Aug 14, 2012 at 11:13 AM, David Lindström
wrote:
> Hi, I didn't know where to put this. I'm trying to use a cygwin build of GCC
> for arm (binaries from gnuarm.com). When I build a simple dummy application
> just doing some matrix multiplications in a loop, it creates a nice
> executable f
On 8/14/2012 2:13 PM, David Lindström wrote:
Hi, I didn't know where to put this. I'm trying to use a cygwin build of GCC
for arm (binaries from gnuarm.com). When I build a simple dummy application
just doing some matrix multiplications in a loop, it creates a nice
executable file with debug info
Resolved, I found a file called "include" was added today to my
/usr/local/ directory which was messing up GCC. Removal fixed the
issue.
Chris
On Tue, Dec 7, 2010 at 10:25 PM, chris henry wrote:
> Hello,
>
> I have a bit of an emergency. After running a poorly written makefile
> my gcc compile
leena.padgaon...@patni.com wrote:
> My basic problem is that the cygwin floating addition is giving
different results than VS 2008 for certain float values .Both the
environments are on the same PC. So I was wondering about the floating
point format used in cygwin.
>
> Btw, the makefile which
leena.padgaon...@patni.com wrote:
My basic problem is that the cygwin floating addition is giving
different results than VS 2008 for certain float values .Both the
environments are on the same PC. So I was wondering about the floating
point format used in cygwin.
Btw, the makefile which I am
Brian Dessent wrote:
Angelo Graziosi wrote:
... and in Fortran?
As long as you're using a recent gcc you can just use -mpc64.
How recent?
With GFortran 4.3.1 and
$ cat test_case.0.f90
program test_case
implicit none
integer :: k
integer, parameter :: DP = kind(1.D0),&
N = 2
Angelo Graziosi wrote:
> ... and in Fortran?
As long as you're using a recent gcc you can just use -mpc64.
Brian
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:
Dave Korn wrote:
Take a look at the (legendary) GCC PR323:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323
... and in particular comment #60:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323#c60
... which has a bit of code you can adapt (google for the definition of
_FPU_SETCW, it's an inline a
> From: [EMAIL PROTECTED]
> To: [EMAIL PROTECTED]; cygwin@cygwin.com
> Date: Mon, 4 Aug 2008 09:40:36 -0700
> Subject: RE: cygwin gcc: Different numerical results in thread vs in main()
>
> 1) The result from the within thread calculation matches my Mac output (note
> th
nt: Monday, August 04, 2008 8:06 AM
To: Richard Stanton; cygwin@cygwin.com
Subject: RE: cygwin gcc: Different numerical results in thread vs in main()
> Try compiling with -ffloat-store then report back. google for
> "float-store excess precision gcc" to understand why th
Richard Stanton wrote on 04 August 2008 15:29:
> Thanks for the helpful information, David. Oddly, -ffloat-store doesn't
> seem to make any difference:
No, unfortunately it can't be assumed to; it'll only come into play if the
results get spilled to memory, rather than living in (x87) register
: cygwin@cygwin.com
> Date: Mon, 4 Aug 2008 07:29:14 -0700
> Subject: Re: cygwin gcc: Different numerical results in thread vs in main()
>
> Thanks for the helpful information, David. Oddly, -ffloat-store doesn't seem
> to make any difference:
>
> [c:\projects\threads]g
anton
Subject: RE: cygwin gcc: Different numerical results in thread vs in main()
Try compiling with -ffloat-store then report back. google for
"float-store excess precision gcc" to understand why this may help.
I don't recommend -ffloat-store as a fix, but it can help diagnose
Richard Stanton wrote:
> Main:t/1+t =0.0005609048868329022342546
> Thread 0: t/1+t =0.0005609048868329021258344
> Thread 1: t/1+t =0.0005609048868329021258344
> Thread 2: t/1+t =0.0005609048868329021258344
> Thread 3: t/1+t =0.0005609048868329021258344
The difference i
Tim Chan wrote:
> Hi! I am using gcc and g++ on cygwin. How come I can't
> use the machine and processor specific options such as
> -68hc12. How can I take advantage of m68hc11.md?
The gcc included with Cygwin is a native gcc, which means it creates
executables that run under Windows on the IA-32
On 23 July 2006 12:37, MariLiza Koukouli wrote:
>>> Does this mean anything to anyone?
>
>> It means that PBGroutines.c has failed to include
>> some vital header or
>> other. Whatever the word before "off64_t" on line 7 is, it should have
>> been defined and it hasn't been.
>
> Hi Dave,
> tha
>> Does this mean anything to anyone?
> It means that PBGroutines.c has failed to include
>some vital header or
>other. Whatever the word before "off64_t" on line 7
>is, it should have been
>defined and it hasn't been.
Hi Dave,
thanks for replying. I would agree with you on that
one, but then
On 21 July 2006 15:59, MariLiza Koukouli wrote:
> Hi all,
>
> I am using the CygWin environent, CYGWIN_NT-5.1, i.e.
> on Windows XP. I am trying to compile a piece of code
> that contains both F77 and C subroutines. G77 works
> fine and compiles without problems but GCC complains
> about somethin
Christopher Faylor wrote:
On Thu, Dec 15, 2005 at 05:45:40AM -0800, Tim Prince wrote:
Piero Silvestri wrote:
Thanks Brian, now -mwindows is clear to me, and the strange linker
problem has gone, but I have one more question on -mno-cygwin option.
When I installed the latest release of Cygwin
On Thu, Dec 15, 2005 at 05:45:40AM -0800, Tim Prince wrote:
>Piero Silvestri wrote:
>>Brain wrote:
>>>-mno-cygwin essentially turns gcc into the gcc provided by mingw.org.
>>>Read the docs/wiki/faq/etc at that site for more information. Note
>>>that when you use gcc -mno-cygwin your search paths w
Tim Prince wrote:
Going further on, more recent gfortran and libstdc++ versions employ
__builtin_pow, and that is failing for my installation. I suppose I'll
have to search for a work-around.
They tell me __builtin_pow should have been taken care of in 'make
bootstrap.' I'll have another g
Piero Silvestri wrote:
Brain wrote:
-mno-cygwin essentially turns gcc into the gcc provided by mingw.org.
Read the docs/wiki/faq/etc at that site for more information. Note that
when you use gcc -mno-cygwin your search paths will be modified so that
no Cygwin libraries/headers will be found, i
Piero Silvestri wrote:
> But then I downloaded the gcc 4.0.2 sources, which I compiled in Cygwin with
> the old gcc provided, so now I have a second version of gcc currently
> working. The problem is that this version has some problem with
> the -mno-cygwin option; if I use it when compiling I get
Brain wrote:
-mno-cygwin essentially turns gcc into the gcc provided by mingw.org.
Read the docs/wiki/faq/etc at that site for more information. Note that
when you use gcc -mno-cygwin your search paths will be modified so that
no Cygwin libraries/headers will be found, instead the mingw ones wi
Piero Silvestri wrote:
> - I'm looking for some documentation about -mno-cygwin and -mwindows
> options, which I can't find neither in the gcc on-line manual, nor in the
> gcc man pages, nor in the CygWin manual. Where they come from? Using the
> first makes the compiler complain about a missing c
Piero Silvestri wrote:
[snip]
> and some other Unix-like OS, so I decided to go for Qt, a multiplatform
> library that seems good for my needs. This choice forced me to change my
> compiler, so I decided to use gcc.
You are aware that Qt for Windows installs (optional) the MingW environment
(gcc/g
On 8/23/05, Christopher Faylor <[EMAIL PROTECTED]> wrote:
> On Tue, Aug 23, 2005 at 04:30:28PM -0400, Igor Pechtchanski wrote:
> >On Tue, 23 Aug 2005, Christopher Faylor wrote:
..snip..
> >>Checking up on this posting problem, I see that it is the standard
> >>problem with attempting to send html e
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to René Berber on 8/23/2005 4:48 PM:
> First, the line above should be written like:
>
>make -f gcc-mingw.mak "CXXFLAGS_COMMON=-mno-cygwin -I/usr/include/mingw"
>
> A space between -f and the makefile name.
Actually, make, like any oth
Juan Carlos Morataya wrote:
> I think that I need to Building a native STLport with Cygwin gcc in my
> installed system by the mean of
>
> make -fgcc-mingw.mak "CXXFLAGS_COMMON=-mno-cygwin -I/usr/include/mingw"
>
> is that correct?
There is no need to build STLport, since gcc comes with a full
Juan Carlos Morataya wrote:
> I think that I need to Building a native STLport with Cygwin gcc in my
> installed system by the mean of
>
> make -fgcc-mingw.mak "CXXFLAGS_COMMON=-mno-cygwin -I/usr/include/mingw"
>
> is that correct?
No.
> If so... I do it but my system doesn't found the gcc-mi
I think that I need to Building a native STLport with Cygwin gcc in my
installed system by the mean of
make -fgcc-mingw.mak "CXXFLAGS_COMMON=-mno-cygwin -I/usr/include/mingw"
is that correct?
If so... I do it but my system doesn't found the gcc-mingw.mak make file...
some idea about this issue
Christopher Faylor
Enviado el: Martes, 23 de Agosto de 2005 04:17 p.m.
Para: cygwin@cygwin.com
Asunto: Re: Cygwin gcc and g90 compilers...
On Tue, Aug 23, 2005 at 04:30:28PM -0400, Igor Pechtchanski wrote:
>On Tue, 23 Aug 2005, Christopher Faylor wrote:
>>On Tue, Aug 23, 2005 at 03:28:1
On Tue, Aug 23, 2005 at 04:30:28PM -0400, Igor Pechtchanski wrote:
>On Tue, 23 Aug 2005, Christopher Faylor wrote:
>>On Tue, Aug 23, 2005 at 03:28:17PM -0400, Igor Pechtchanski wrote:
>>>It's usually a good idea to try to resolve any posting problem with the
>>>list administrator/owner, instead of
On Tue, 23 Aug 2005, Christopher Faylor wrote:
> On Tue, Aug 23, 2005 at 03:28:17PM -0400, Igor Pechtchanski wrote:
> >It's usually a good idea to try to resolve any posting problem with the
> >list administrator/owner, instead of sending e-mail to random list
> >participants. I'm forwarding this
On Tue, Aug 23, 2005 at 03:28:17PM -0400, Igor Pechtchanski wrote:
>It's usually a good idea to try to resolve any posting problem with the
>list administrator/owner, instead of sending e-mail to random list
>participants. I'm forwarding this message to the list, but if you have
>trouble posting i
Juan,
It's usually a good idea to try to resolve any posting problem with the
list administrator/owner, instead of sending e-mail to random list
participants. I'm forwarding this message to the list, but if you have
trouble posting in the future, try contacting
cygwincom> instead.
This top-poste
Jim:
Hi. On Solaris9 I use leak and there are no leaks, and I see no errors
at all.
One of the errors on Cywin, using the most Current Cygwin1.dll occurs
before any memory is created, ner the top of main():
if ((Portfolio->ptr_err = fopen (infoFile, "a")) == NULL) {
...
Now, I do have a
Lester Ingber wrote:
Jim:
Hi. On Solaris9 I use leak and there are no leaks, and I see no errors
at all.
Valgrind implements an x86 interpreter and, among other things,
checks use of uninitialized memory or referencing outside of
allocated memory. Dave's conjecture was that the problem was
of th
Jim Kleckner wrote:
Dave Korn wrote:
...
Maybe we should try and port the free open-source equivalent valgrind
(http://valgrind.kde.org/) instead? I haven't ever looked at this,
but it ought
to be possible. I note that you can use (a special variant version
of) valgrind
to verify win32 apps
Dave Korn wrote:
-Original Message-
From: cygwin-owner On Behalf Of Jim Kleckner
Sent: 10 December 2004 19:01
We used to use Purify to find these sorts of problems
often just by running the program once. Unfortunately
for us using cygwin, Purify appears to have moved toward
a firm depende
> -Original Message-
> From: cygwin-owner On Behalf Of Jim Kleckner
> Sent: 10 December 2004 19:01
> We used to use Purify to find these sorts of problems
> often just by running the program once. Unfortunately
> for us using cygwin, Purify appears to have moved toward
> a firm dependence
Dave Korn wrote:
-Original Message-
From: cygwin-owner On Behalf Of Lester Ingber
Sent: 10 December 2004 16:14
...
Your code has a bug: a stray pointer or array overwrite that is trashing some
memory. The only reason you get away with it on Solaris is by sheer luck;
either the stack or h
> -Original Message-
> From: cygwin-owner On Behalf Of Lester Ingber
> Sent: 10 December 2004 16:14
> I have a good-sized vanilla-C code that was running just fine a month
> or two ago under XPPro/Cygwin and under SPARC/Solaris9, and STILL runs
> just fine under SPARC/Solaris9.
> All my o
At 09:23 AM 6/5/2004, you wrote:
Hello Tim,
Igor wrote:
>> Also, in the future, please *attach* your cygcheck
>> output to your messages
Tim wrote:
> Looking at the Cygwin page on reporting errors, it
> says:
> "Run cygcheck -s -v -r > cygcheck.out and include that
> file as an attachment in your r
Hello Tim,
Igor wrote:
>> Also, in the future, please *attach* your cygcheck
>> output to your messages
Tim wrote:
> Looking at the Cygwin page on reporting errors, it
> says:
> "Run cygcheck -s -v -r > cygcheck.out and include that
> file as an attachment in your report."
> Text attachments ne
Hallo Matthieu,
> Could someone explain me why gcc cygwin compiler take so long to build a
> simple hello world program compared with mingw ?
The system calls go through cygwin1.dll and not directly to the system
(for every for executable linked against cygwin1.dll).
You may speed up your compil
On Fri, 4 Jun 2004, Hannu E K Nevalainen wrote:
> > From: Igor Pechtchanski
> > Sent: Friday, June 04, 2004 6:08 PM
>
> > On Fri, 4 Jun 2004, Matthieu VIAL wrote:
> >
> > > Hello,
> > >
> > > Could someone explain me why gcc cygwin compiler take so long to build a
> > > simple hello world program
> From: Igor Pechtchanski
> Sent: Friday, June 04, 2004 6:08 PM
> On Fri, 4 Jun 2004, Matthieu VIAL wrote:
>
> > Hello,
> >
> > Could someone explain me why gcc cygwin compiler take so long to build a
> > simple hello world program compared with mingw ?
>
> Cygwin is a POSIX emulation layer. Usin
--- Igor Pechtchanski <[EMAIL PROTECTED]> wrote:
>...
> Also, in the future, please *attach* your cygcheck
> output to your messages
> as an uncompressed text attachment, instead of
> including it inline, since
> that produces false positives in archive searches.
> Igor
Looking at the Cygwi
On Fri, 4 Jun 2004, Matthieu VIAL wrote:
> Hello,
>
> Could someone explain me why gcc cygwin compiler take so long to build a
> simple hello world program compared with mingw ?
Cygwin is a POSIX emulation layer. Using the POSIX emulation is bound to
be less efficient than running the native app
Hi Gerrit,
Yes, I managed to fix this. I ended up wiping and reinstalling the
cygwin binaries, which were getting crufty anyway. If I run into the
problem again, I'll try your suggestion.
Thanks,
Heflin
smime.p7s
Description: S/MIME Cryptographic Signature
Hallo Heflin,
Friday, 19.03.2004 00:31 you wrote:
> Richard Campbell wrote:
>>>The symptom is pretty straight forward, on a straight command line of:
>>>
>>>gcc foo.c
>>>
>>>I get a pop up and a system log message which says:
>>>Application popup: cc1.exe - Application Error : The application f
Richard Campbell wrote:
The symptom is pretty straight forward, on a straight command line of:
gcc foo.c
I get a pop up and a system log message which says:
Application popup: cc1.exe - Application Error : The application failed
to initialize properly (0xc022). Click on OK to terminate the
>>Application popup: cc1.exe - Application Error : The application failed
>>to initialize properly (0xc022). Click on OK to terminate the
>>application.
>
>Let's not see every single problem as somehow related to this error
>without going through the standard problem reporting exercise first.
On Thu, Mar 18, 2004 at 04:38:00PM -0500, Richard Campbell wrote:
>>The symptom is pretty straight forward, on a straight command line of:
>>
>>gcc foo.c
>>
>>I get a pop up and a system log message which says:
>>
>>Application popup: cc1.exe - Application Error : The application failed
>>to initi
>The symptom is pretty straight forward, on a straight command line of:
>
>gcc foo.c
>
>I get a pop up and a system log message which says:
>
>Application popup: cc1.exe - Application Error : The application failed
>to initialize properly (0xc022). Click on OK to terminate the
>application.
Hello Milton,
Wednesday, November 5, 2003, 6:34:01 AM, you wrote:
> Greetings,
> When building LyX version 1.3.x from source on Cygwin, I had problems
> during the final link stage where gcc-3.3.1 reported some undefined
> symbols. All of the 'undefined' symbols were actually defined in the Ly
Please check out the project web page for links to available information
and ports: http://cygwin.com/ .
If you don't see what you need there, then the cygwin mailing list is
the best place to make observations or get questions answered.
Information on the mailing list is available at the project
Dave,
On Tue, May 27, 2003 at 10:45:22AM -0400, David Abrahams wrote:
> Jason Tishler <[EMAIL PROTECTED]> writes:
> >> boost_python.dll\gcc\debug-python\runtime-link-dynamic\boost_python.lib"
> >> "c:\build\libs\
> >>
> >> python\build\bin\boost_python.dll\gcc\debug-python\runtime-link-
Jason Tishler <[EMAIL PROTECTED]> writes:
> Dave,
>
> On Fri, May 23, 2003 at 08:20:38AM -0400, David Abrahams wrote:
>> Recently I've begun to see the following link errors when building
>> some of the Boost.Python test suite extension modules using Cygwin gcc
>> (version 2 or 3, doesn't matter)
Christopher Faylor wrote:
> Still talking about this, eh? Somehow I thought it had died down
> before I went on my business trip.
>
I am truely sorry Chris. This email was not directed to you at all.
Indeed, in the end, I was more than satisfied with your response.
This was simply a response t
--- Danny Smith <[EMAIL PROTECTED]> wrote: > Brian Ford wrote:
>
> > Vanilla gcc 3.2.x is NOT ABI compatible with Cygwin's pre 3.2 gcc, fact.
> > I wanted to know why this was allowed to persist given the simple patch
> > required to fix it, question. I had seen Mr. Faylor make statements
> > be
On Sun, Mar 16, 2003 at 09:01:23PM -0500, Christopher Faylor wrote:
>On Mon, Mar 17, 2003 at 12:59:21PM +1100, Danny Smith wrote:
>>Brian Ford wrote:
>>
>>> Vanilla gcc 3.2.x is NOT ABI compatible with Cygwin's pre 3.2 gcc, fact.
>>> I wanted to know why this was allowed to persist given the simple
On Mon, Mar 17, 2003 at 12:59:21PM +1100, Danny Smith wrote:
>Brian Ford wrote:
>
>> Vanilla gcc 3.2.x is NOT ABI compatible with Cygwin's pre 3.2 gcc, fact.
>> I wanted to know why this was allowed to persist given the simple patch
>> required to fix it, question. I had seen Mr. Faylor make state
Brian Ford wrote:
> Vanilla gcc 3.2.x is NOT ABI compatible with Cygwin's pre 3.2 gcc, fact.
> I wanted to know why this was allowed to persist given the simple patch
> required to fix it, question. I had seen Mr. Faylor make statements
> before to the effect of: doubles in structures are not tha
Still talking about this, eh? Somehow I thought it had died down
before I went on my business trip.
On Fri, Mar 14, 2003 at 11:57:02AM -0600, Brian Ford wrote:
>Vanilla gcc 3.2.x is NOT ABI compatible with Cygwin's pre 3.2 gcc,
>fact. I wanted to know why this was allowed to persist given the
>s
On Thu, 13 Mar 2003, Ronald Landheer-Cieslak wrote:
> On Wed, 12 Mar 2003, Brian Ford wrote:
>
> > Max Bowsher wrote:
> > >Brian Ford wrote:
> > >> I thought I had a legitimate concern and question, not one that
> > >> deserved "just" a sarcastic response.
> > >Yes, it was sarcastic, but don't tak
> >If you want pickled eggs with your free beer, you may have to wait. Myself,
I
> >can't understand why the barman can't put the foam on the bottom
>
> But I don't like beer! What other beverages do you provide for free?
This reminds me of the Monty Python "Bookshop" sketch with a customer
dema
On Wed, 12 Mar 2003, Brian Ford wrote:
> Max Bowsher wrote:
> >Brian Ford wrote:
> >> I thought I had a legitimate concern and question, not one that
> >> deserved "just" a sarcastic response.
> >Yes, it was sarcastic, but don't take it personally. Chris is *busy* and
> >this is quite a minor issu
On Thu, Mar 13, 2003 at 08:33:27AM +1100, Danny Smith wrote:
>Brian Ford wrote:
>>
>> Gee. I hope Cygwin, and anything else you compile with that compiler
>> for Cygwin, does not have structures containing doubles. Without
>> MASK_ALIGN_DOUBLE in TARGET_SUBTARGET_DEFAULT of gcc/config/i386/cygwi
Brian Ford wrote:
>
> Gee. I hope Cygwin, and anything else you compile with that compiler
> for Cygwin, does not have structures containing doubles. Without
> MASK_ALIGN_DOUBLE in TARGET_SUBTARGET_DEFAULT of gcc/config/i386/cygwin.h,
> the standard Cygwin compiler and vanilla gcc are ABI incomp
Brian Ford wrote:
>Cygwin's gcc has an extensive number of patches and is pre 3.2. There
>must be a reason for this. Maybe it is just volunteer time, but somehow
>I doubt it.
Christopher Faylor wrote:
>There is no hidden agenda here.
>
Ok. But is it "kosher" for me to submit and revise patche
On Wed, Mar 12, 2003 at 12:43:47PM -0600, Brian Ford wrote:
>Cygwin's gcc has an extensive number of patches and is pre 3.2. There
>must be a reason for this. Maybe it is just volunteer time, but somehow I
>doubt it.
There is no hidden agenda here.
If you want to improve the trunk version of gc
On Wed, Mar 12, 2003 at 12:53:50PM -0600, Brian Ford wrote:
>Christopher Faylor wrote:
>>For the record, Danny Smith is working on getting the cygwin patches
>>into gcc. But, guess what? He doesn't get paid to do this any more
>>than I do.
>
>None of us do. That is well understood.
That was als
Max Bowsher wrote:
>Yes, it was sarcastic,
Christopher Faylor wrote:
>As was, "Gee. I hope Cygwin, and anything else you compile with that
>compiler for Cygwin, does not have structures containing doubles."
Sorry, I should have phrased this differently. It was not really intended
to be sarcas
Max Bowsher wrote:
>Brian Ford wrote:
>
>> I thought I had a legitimate concern and question, not one that
>> deserved "just" a sarcastic response.
>
>Yes, it was sarcastic, but don't take it personally. Chris is *busy* and
>this is quite a minor issue.
>
We are all *busy*. Well, ABI breakage is n
On Wed, Mar 12, 2003 at 06:19:58PM -, Max Bowsher wrote:
>Brian Ford wrote:
>> I thought I had a legitimate concern and question, not one that
>> deserved "just" a sarcastic response.
>
>Yes, it was sarcastic,
As was, "Gee. I hope Cygwin, and anything else you compile with that
compiler for C
Brian Ford wrote:
> I thought I had a legitimate concern and question, not one that
> deserved "just" a sarcastic response.
Yes, it was sarcastic, but don't take it personally. Chris is *busy* and
this is quite a minor issue.
> It would be easy to accendentally release things for Cygwin that are
At 08:39 2003-03-12, Christopher Faylor wrote:
On Wed, Mar 12, 2003 at 10:13:35AM -0600, Brian Ford wrote:
>On Wed, Mar 12, 2003 at 10:54:13PM -0500, Christopher Faylor wrote:
>
>>FWIW, I build cygwin itself with an unpatched version of gcc several
>>times a day.
>>
>
>Gee. I hope Cygwin, and anyt
I thought I had a legitimate concern and question, not one that deserved
"just" a sarcastic response.
It would be easy to accendentally release things for Cygwin that are ABI
incompatible with Cygwin's gcc.
Why do we persist this way? I would be happy to do the necessary leg work
to make vanilla
On Wed, Mar 12, 2003 at 10:13:35AM -0600, Brian Ford wrote:
>On Wed, Mar 12, 2003 at 10:54:13PM -0500, Christopher Faylor wrote:
>
>>FWIW, I build cygwin itself with an unpatched version of gcc several
>>times a day.
>>
>
>Gee. I hope Cygwin, and anything else you compile with that compiler for
>C
On Wed, Mar 12, 2003 at 10:54:13PM -0500, Christopher Faylor wrote:
>FWIW, I build cygwin itself with an unpatched version of gcc several
>times a day.
>
Gee. I hope Cygwin, and anything else you compile with that compiler for
Cygwin, does not have structures containing doubles. Without
MASK_AL
On Wed, Mar 12, 2003 at 04:33:04PM +0100, Ronald Landheer-Cieslak wrote:
>On Wed, 12 Mar 2003, Tim Prince wrote:
>> On Wednesday 12 March 2003 03:20, Ronald Landheer-Cieslak wrote:
>> > BTW: the FSF-provided gcc doesn't work OOTB on Cygwin, IIRC: there are a
>> > couple of patches to apply and a bi
On Wed, Mar 12, 2003 at 08:43:55PM +1100, Eugene Rosenzweig wrote:
>The latest message in gcc-announce
>http://gcc.gnu.org/ml/gcc-announce/2003/msg1.html says that
>i?86-*-win32 target will be deprecated as from gcc 3.4 (no date set).
If you look in the gcc list where this was discussed you'll
On Wed, 12 Mar 2003, Tim Prince wrote:
> On Wednesday 12 March 2003 03:20, Ronald Landheer-Cieslak wrote:
> > The cygwin target is i686-pc-cygwin
> >
> > That, and Cygwin without gcc would be pretty useless, so I don't worry too
> > much :)
> >
> > rlc
> >
> > BTW: the FSF-provided gcc doesn't work
On Wednesday 12 March 2003 03:20, Ronald Landheer-Cieslak wrote:
> The cygwin target is i686-pc-cygwin
>
> That, and Cygwin without gcc would be pretty useless, so I don't worry too
> much :)
>
> rlc
>
> BTW: the FSF-provided gcc doesn't work OOTB on Cygwin, IIRC: there are a
> couple of patches to
The cygwin target is i686-pc-cygwin
That, and Cygwin without gcc would be pretty useless, so I don't worry too
much :)
rlc
BTW: the FSF-provided gcc doesn't work OOTB on Cygwin, IIRC: there are a
couple of patches to apply and a bit of development to be done each time.
You might say that ther
>Jim - Try the following solution. it worked for me. Write back if it doesn't work
>and I'll generate a more explicit example from my ant build script.
Alan Thompson
>From: "Mike Bresnahan" <[EMAIL PROTECTED]>
>To: <[EMAIL PROTECTED]>
>Subject: RE: Using cygwin and JAVA/JNI
>Date: Wed, 5 Fe
On Wed, Feb 12, 2003 at 04:53:29PM -0600, Brian Ford wrote:
>What is the state of/reason for Cygwin/Mingw specific mods to official
>gcc sources? I assume these mods will eventually make it in to the
>official tree, right? What is the typical migration path?
>
>I ask, because I am trying to do DW
On Mon, Jan 06, 2003 at 02:00:25PM -0500, Jason Tishler wrote:
> Any suggestions on how to best debug this problem or potential root
> causes will be greatly appreciated.
A friend of mine suggested using -Wall to find questionable fetchmail
code that could behave differently under gcc 3.2. The go
Igor,
On Thu, Jan 02, 2003 at 03:03:21PM -0500, Igor Pechtchanski wrote:
> How about doing exactly what the message suggests (see attached)?
I think that I found the best solution -- auto-import the functions by
just removing the "__declspec(dllimport)" indicators. If interested,
see attached.
On Thu, 2 Jan 2003, Jason Tishler wrote:
> The attached code snippet, j2.c, demonstrates a Cygwin specific
> compilation problem that affects many Python shared extension modules:
>
> $ gcc -c j2.c
> j2.c:17: initializer element is not constant
> j2.c:17: (near initialization for `f.ge
I don't think I know something you don't... I am test compiling gcc from
CVS, both the 3.1 branch as well as trunk a.k.a. 3.2 right now. It also
happens that java/libjava/libgcj is coming along, at least in the trunk
and it might show up in a 3.1.1 release. I'd guess a 3.1 release is due
in a week
On Fri, Feb 15, 2002 at 09:14:56AM +0900, Dylan Cuthbert wrote:
>It surely doesn't matter if we aren't distributing our code to anyone
>other than ourselves, otherwise you've probably got millions of
>offenders of the GPL.
Right. If you're only using it internally, you don't have to worry
about
m/personal/utils
- Original Message -
From: "Christopher Faylor" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, February 15, 2002 12:23 AM
Subject: Re: cygwin gcc DLLs loaded by Visual C++ crashing - SOLVED
> On Thu, Feb 14, 2002 at 03:09:47PM +0900, D
On Thu, Feb 14, 2002 at 03:09:47PM +0900, Dylan Cuthbert wrote:
>
>The FAQ/User Manual leads everyone in completely the wrong direction.
>
>If anyone else wants to get CYGWIN C++ programs running as dlls loaded by
>Visual C++ programs, use the attached example as a basis, it is *really*
>simple.
s.com
- Original Message -
From: "Dylan Cuthbert" <[EMAIL PROTECTED]>
To: "Larry Hall (RFK Partners, Inc)" <[EMAIL PROTECTED]>; "Cygwin@Cygwin. Com"
<[EMAIL PROTECTED]>
Sent: Thursday, February 14, 2002 12:06 PM
Subject: Re: cygwin gcc DLLs l
1 - 100 of 102 matches
Mail list logo
