Both Cygwin and mingw use customized versions of gcc. As far as I know,
compiling on Cygwin with -mno-cygwin should be almost exactly the same as
compiling with mingw. But I haven't tried it yet.

My personal reason for preferring Cygwin is that I am (still!) planning a
Linux version of CsoundVST and my associated stuff, and I'm hoping to use
autoconf/automake/libtool to build everything with the same system on
Windows and Linux. I think this goal largely overlaps what John Ramsdell is
doing.

I was rather interested to discover that CsoundVST compiled with Visual C++
version 7.0, and CsoundVST compiled with mingw/gcc 3.2, rendered some
moderately complex Csound pieces in almost exactly the same time:

10/25/2003 11:26 CsoundVST Performance
                                           MinGW
                  VC++ 7.0         Unstripped    Stripped
Koch.py           91.13             99.23         93.925
                  88.45                           92.724
                  90.82                           93.144
                 270.40                          279.79
                                                             0.96642518
Lindenmayer.py   118.42                          122.416
                 137.74                          121.745
                 149.01                          122.236
                 405.17                          366.40
                                                             1.10582783
                 675.57                          646.19
                                                             1.04546805


============================================
Michael Gogins
gogins at pipeline period com
Irreducible Productions
CsoundVST, an extended version of Csound for programming music and sound
Available at http://sourceforge.net/projects/csound/
============================================


----- Original Message ----- 
From: "Gabriel Maldonado" 
To: "Csound Developers Discussion List" 
Sent: Wednesday, November 26, 2003 3:59 AM
Subject: [CSOUND-DEV:3534] Re: widgets.cpp


> What are the compiler difference between MinGW and cygwin? Source code
> written for the first one is incompatible with the other one? Or there
> is a newer gcc version contained in one of these?
>
> Is a source code compilable (apart the libraries and the
> platform-dependent stuff) by all gcc flavours of the various platforms
> having the same release number?
>
> Now I'm using MinGW-devcpp (that is quite convenient) and (mainly)
> msvc6, i.e. I'm writing code that is compilable by both compilers. Why
> should I pass to cygwin?
>
> Gab
>
> Michael Gogins wrote:
> > I'm using Visual Studio .NET (Visual C++ version 7.0) and Dev-C++ (MinGW
> > with gcc 3.2). I plan to switch to Cygwin -mno-cygwin with the latest
Cygwin
> > version of gcc, whatever that is.
> >
> > It's conceivable that I'd switch to entirely Linux, if there were
something
> > like Cool Edit Pro and Cubase SX on Linux. No luck so far, though it's
close
> > for sound editors what with Ardour and good single-file editors.
> >
> > ============================================
> > Michael Gogins
> > gogins at pipeline period com
> > Irreducible Productions
> > CsoundVST, an extended version of Csound for programming music and sound
> > Available at http://sourceforge.net/projects/csound/
> > ============================================
> >
> >
> > ----- Original Message ----- 
> > From: "steven" 
> > To: "Csound Developers Discussion List" 
> > Sent: Tuesday, November 25, 2003 8:51 PM
> > Subject: [CSOUND-DEV:3519] Re: widgets.cpp
> >
> >
> >
> >>I can't verify for older compilers as I'm using gcc 3.3 as well.
> >>
> >>BTW: Are you using John R's autobuild system or Visual Studio?  I'm
> >>trying to use
> >>
> >>autoreconf -i --force
> >>aclocal
> >>autoconf
> >>configure
> >>make
> >>
> >>and get stopped at main.c due to SIGALRM not being defined.
> >>
> >>This is using Cygwin 3.3.1 on win2k.
> >>
> >>Looking at the change in widgets.cpp, it looks to look for cygwin but
> >>not what version.  This all should probably be done with the
> >>autoheader.h/config.h stuff to check if strstream.h or sstream.h exist,
> >>then #ifdef them in depending (same with fstream/fstream.h).
> >>
> >>steven
> >>
> >>
> >>Robert McNulty Junior wrote:
> >>
> >>
> >>>I changed widgets to work with old compilers as well as new.
> >>>Could you update and try it to verify, Steven?
> >>>I think I got the hang of this.
> >>>Bobby
> >>>
> >>>
> >>>
> >>
> >
> >
>
>
> -- 
> Gabriel Maldonado
> http://csounds.com/maldonado
> --
>

"Michael Gogins"  writes:

> Both Cygwin and mingw use customized versions of gcc. As far as I
> know, compiling on Cygwin with -mno-cygwin should be almost exactly
> the same as compiling with mingw. But I haven't tried it yet.

I'm not sure this is true.  When I use MinGW, I find I must include
mingwm10.dll in my distribution.  I was led to believe the advantage
of MinGW was it's easy to produce distributions without DLLs.  Oh
well...

> My personal reason for preferring Cygwin is that I am (still!)
> planning a Linux version of CsoundVST and my associated stuff, and
> I'm hoping to use autoconf/automake/libtool to build everything with
> the same system on Windows and Linux. I think this goal largely
> overlaps what John Ramsdell is doing.

My goal is to create a system that builds on every system supported by
libtools's libltdl dynamic linking package, i.e,

   * `dlopen' (Solaris, Linux and various BSD flavors)

   * `shl_load' (HP-UX)

   * `LoadLibrary' (Win16 and Win32)

   * `load_add_on' (BeOS)

I think Mac OS X fits in the BSD category.  Mac users, is that true?

While I currently prefer Linux, I see no reason to not support more
than just Windows and Linux.

John

I find this message really odd!
>>>>> "John" == John D Ramsdell  writes:

 John> My goal is to create a system that builds on every system supported by
 John> libtools's libltdl dynamic linking package, i.e,

 John>    * `dlopen' (Solaris, Linux and various BSD flavors)

 John>    * `shl_load' (HP-UX)

 John>    * `LoadLibrary' (Win16 and Win32)

 John>    * `load_add_on' (BeOS)

 John> I think Mac OS X fits in the BSD category.  Mac users, is that true?

 John> While I currently prefer Linux, I see no reason to not support more
 John> than just Windows and Linux.

What do you thing we have been doing for the last 12 years?

==John ffitch

jpff@cs.bath.ac.uk writes:

> What do you thing we have been doing for the last 12 years?

John,

I was trying to say that a system built using autoconf, automake, and
libtool should support many platforms.  Michael's note to which I was
replying mentioned only Linux and Windows.  By the way, the additions
I've made to the csound module do not break the original build method,
and the README labels the new build method as experimental.  For the
csound module, I see no reason not to support both build methods, and
let people choose what's best for them.  Assuming there are no
objections to me moving the source files at top-level into a csound
directory, I will update the various Makefile templates and makef
files as needed so that the original build system continues to
function.

John

I updated ccsound.c so it uses either winFLTK or winX11 on systems
determined to support graphing.  I tried to enable graphing on Windows
without FLTK.  I specified wincwin.o and cwin.o as the graphing
objects, but when compiling cwin.cpp using MinGW, header files are
missing.  What objects should I be using?  When using MinGW, maybe one
gets graphics only via FLTK.

John

cwin.cpp uses the Microsoft Fondation Classes (MFC), which are unlikely 
ever to appear in a Gnu/GPL environment. It is a HUGE class library, 
much more than a small bunch of header files. In any case, I beleive 
John had a new GUI (FLTK?) on the go for Csound on the PC, so that 
Winsound can be put out to pasture, at last. A minimalist Win32 GUI 
would not be a particuarly bad thing to put together; that would be able 
to be compiled on MinGW etc.


Richard Dobson



John D. Ramsdell wrote:
> I updated ccsound.c so it uses either winFLTK or winX11 on systems
> determined to support graphing.  I tried to enable graphing on Windows
> without FLTK.  I specified wincwin.o and cwin.o as the graphing
> objects, but when compiling cwin.cpp using MinGW, header files are
> missing.  What objects should I be using?  When using MinGW, maybe one
> gets graphics only via FLTK.
> 
> John
> 
> 

For work, I had to install Cygwin on my laptop, so I tested the
installation by building Csound.  I had no problems when I disabled
windows with the -enable-windows=no configure option.  I then tested
the program that repeatly runs Csound and it successfully rendered the
same input twenty times.  This is the test driver that causes Csound
built on MinGW to die a horrible death after only a few renderings.
Csound must be exercising buggy MinGW libraries routines.  I guess
I'll switch to Cygwin from now on.

I was unable to build Csound with FLTK on Cygwin.  It's that same
problem with widgets.cpp we had before.  Bobby, I changed the file to
a previous state because your changes seem to break John ffitch.
Please make your fixes in a manor that is only visible on Cygwin.

John

Are you using -mno-cygwin?  The compiles should be largely the same when
-mno-cygwin and mingw.  Also, something I learned in general when
building the fluidOpcodes stuff, you must be careful *not* to mix cygwin
generated executables and mingw/-mno-cygwin/microsoft generated dll's. 
This actually won't work at all (you'll get linker errors).  

FLTK libraries on windows come window-compiled, as do most anything
that's GNU-compiled and publicly released.  To compile against FLTK on
windows, you *have* to use -mno-cygwin or mingw, or compile FLTK
yourself with Cygwin. 

Also, you can not release anything Cygwin-compiled publicly without the
end-user having libcygwin.dll or statically-compiling in libcygwin.a
which bloats the executable.

I'd prefer in the end *not* to use Cygwin without -mno-cygwin and that
the autoconf stuff check to do so.  

(Someone feel free to correct me if I'm wrong in any of the above).

Thanks,
steven


On Thu, 2003-12-04 at 07:20, John D. Ramsdell wrote:
> For work, I had to install Cygwin on my laptop, so I tested the
> installation by building Csound.  I had no problems when I disabled
> windows with the -enable-windows=no configure option.  I then tested
> the program that repeatly runs Csound and it successfully rendered the
> same input twenty times.  This is the test driver that causes Csound
> built on MinGW to die a horrible death after only a few renderings.
> Csound must be exercising buggy MinGW libraries routines.  I guess
> I'll switch to Cygwin from now on.
> 
> I was unable to build Csound with FLTK on Cygwin.  It's that same
> problem with widgets.cpp we had before.  Bobby, I changed the file to
> a previous state because your changes seem to break John ffitch.
> Please make your fixes in a manor that is only visible on Cygwin.
> 
> John
> 
> 

stevenyi  writes:

> I'd prefer in the end *not* to use Cygwin without -mno-cygwin and
> that the autoconf stuff check to do so.

So the action item is to change configure.ac in some specific way?
When $host_os matches cygwin*, should -mno-cygwin be added to CFLAGS,
CXXFLAGS, LDLIBS, or LIBS?  I'm new to Cygwin, you'll have to hold my
hand on this one.

John

OK.


-----Original Message-----
From: owner-csound-dev@eartha.mills.edu
[mailto:owner-csound-dev@eartha.mills.edu]On Behalf Of John D. Ramsdell
Sent: Thursday, December 04, 2003 9:21 AM
To: Csound Developers Discussion List
Subject: [CSOUND-DEV:3631] widgets.cpp


For work, I had to install Cygwin on my laptop, so I tested the
installation by building Csound.  I had no problems when I disabled
windows with the -enable-windows=no configure option.  I then tested
the program that repeatly runs Csound and it successfully rendered the
same input twenty times.  This is the test driver that causes Csound
built on MinGW to die a horrible death after only a few renderings.
Csound must be exercising buggy MinGW libraries routines.  I guess
I'll switch to Cygwin from now on.

I was unable to build Csound with FLTK on Cygwin.  It's that same
problem with widgets.cpp we had before.  Bobby, I changed the file to
a previous state because your changes seem to break John ffitch.
Please make your fixes in a manor that is only visible on Cygwin.

John