----- Original Message -----
From: "Zed A. Shaw" <zedshaw@...>
To: "mingw-users" <MinGW-users@...>
Sent: Tuesday, June 04, 2002 10:41 AM
Subject: Re: [Mingw-users] Re: Potato Chips
> I do know how to use Makefiles (and autoconf, and automake, and imake, and
> Ant, and bsd make, and dmake, and many, many more), but I choose to use
> Scons because it is more powerful than the mess that is
> Makefile/automake/autconf. Things were MUCH worse with automake, as I
> couldn't even get automake to properly configure the app. It kept
> stuff from all kinds of places. M4 macros came from Cygwin, but the
> autoconf .sh scripts came from MinGW. It was a nightmare. With Scons,
> able to compile on just about everything (except Win32) with no
Does Scons work with MSVC? If not, you may find that MSVC is not much easier
to use than Mingw. If so, it should not take much work to get it to work
with Mingw, but I can only guess...
> Considering my application (http://bombyx.sourceforge.net) now runs on
> platforms (Linux, FreeBSD, MacOSX, and Win32), I think I know a bit of
> something about software configuration management and porting. But, while
> your non-trivial application may work, mine doesn't. This is probably for
> several reasons which are all my fault (because, true to open source form,
> mingw is ALWAYS right, and I'm always wrong, since no one has ever heard
> user centered design). I simply don't have the time to mess with it when
> there is a perfectly good alternative.
If you mean that MSVC is a "perfectly good alternative" then I think many
people would disagree, but lets not get caught up in that.
> I'm sure, in a few years, MinGW will be good enough for me to work with
> seamlessly. Until then, I'll just play with it and track the project. I
> still think something like fink would help this.
If you are talking about Mingw being compatible with "Scons", it will only
work "seamlessly" when somebody takes the time to work on it. I don't know
anything about Scons but I am sure it would have taken a little bit of work
on each of its platforms (e.g. MacOS).
> Finally, if MinGW is not supposed to work with Cygwin or MSYS, then how do
> YOU use Makefiles? You need a shell to run them right? You need a bourne
> compatible shell to do autoconf and friends right? And you don't use MSYS
> or Cygwin? I'd really like to know what people use for their build
> environment, because there is obviously some magic that I'm missing to get
> this all working.
MSYS is definitely supposed to work with Mingw: it is designed to provide
the Unix-style shell that you are talking about. However, MSYS is definitely
not meant to work with Cygwin, and Mingw is not designed to work with Cygwin
I just downloaded FLTK and built it with Mingw (gcc 3.1 + mingw-runtime 2.0
+ w32api 1.4) and MSYS, with a few minor modifications. I think you may have
been confused by the FLTK documentation, which offers two alternatives: 1)
using Cygwin only to build FLTK dependent on cygwin1.dll (using configure);
2) using Cygwin shell with Mingw compiler to build a Windows native version,
with Mingw-specific makefiles (not configure). If you use the first option,
your entire application must be built with Cygwin only. MSYS is designed
specifically to provide the parts of Cygwin that (2) requires, so Cygwin is
not required for building a Windows native library.
I have attached the modifications, which are necessary because:
1. A few math functions have been added to mingw-runtime so FLTK should not
2. The config.h provided for Mingw incorrectly uses things like "#define
HAVE_SCANDIR 0" instead of "#undef HAVE_SCANDIR".
3. You should change the prefix to your Mingw directory to make linking
easier and to avoid differences with the mounting of /usr.
4. The Mingw-specific makefile has not been kept 100% up to date for the
You should be able to get it to work with Mingw gcc 2.95.3 too, possibly
with even less modification.
> Anyway, I'll stop beating this dead horse. I'm not bashing the project, I
> just gave up on it for now.
Come now, you have hardly given people a chance to respond to your
> On 6/3/02 6:17 PM, "Oscar Fuentes" <ofv@...> wrote:
> > "Zed A. Shaw" <zedshaw@...> writes:
> >> On 6/3/02 5:11 PM, "Oscar Fuentes" <ofv@...> wrote:
> >> Oscar,
> >> Because, if I use Cygwin, and try to install say, FLTK
> >> (http://www.fltk.org), it will put them in /usr/local of CYGWIN, but
> >> run MinGW (from Cygwin) and tell it -lfltk, it tries to load the
> >> from MinGW's /usr/local.
> >> So, if I have my libraris in, C:\cyginw\usr\local, and MinGW is in
> >> then MinGW tries to load them from C:\mingw\usr\local, and not
> >> C:\cygwin\usr\local. Even then it is still not clear where MinGW
> >> things to be, and setting stuff like LIBPATH is just not honored by
> >> So, what I'm forced to do is load MSYS to do any linking, and muck with
> >> paths where software is installed in order to get MinGW to properly
> >> right headers and libraries during compile. Then, if I'm lucky, I
> >> into problems with ranlib not finding things and such.
> >> Either way, it's a nightmare. I've found that I can do about 90% of
> >> everything in MSYS, but I use the Scons build system
> >> which needs python. Since MSYS hasn't got python working (trust me, I
> >> tried), and since I can't seamlessly call Cygwin binaries from MSYS,
> >> basically stuck working in this weird half-assed MSYS/Cygwin world that
> >> barely works.
> >> In VC++, I make project, I add files, I setup libraries and headers, I
> >> build, I get binary. Easy.
> >> So, that's why I think something like fink
> >> MSYS would be great. Then, it would be easier to port and distribute
> >> software.
> >> Anyway, that's what I think.
> > From your description, my conclussions are this:
> > 1. Learn that MinGW is not a Cygwin part. It is not required that
> > MinGW works well with Cygwin. Much less MSYS. Earnie explicitly
> > arranged things for Cygwin executables not working with MSYS.
> > 2. Learn how to use Makefiles. They are *much* more powerful and
> > efficient than whatever IDE is around.
> > In any case, you are free from moving libraries to whatever directory
> > you want. Although LIBPATH should be an easy to fix issue, the -L
> > option works fine with MinGW, that is, if you specify the paths in the
> > correct way (remember: MinGW's gcc is a Windows native system).
> > I'm using MinGW for almost a year now and my far-from-being-trivial
> > main project builds correctly either with MSYS, Cygwin or NT
> > shells. The libraries and header files are scattered on several disk
> > drives.
> Zed A. Shaw