[OS] A bit more on ASL and Msys

[Lou Hafer]

Kipp, Jun,

	I took time on Wednesday to play with building OS/trunk under Msys, with
ASL in the mix.  It looks like you've removed the use of the /mingw/include, and
I had no problems there.  I still have difficulty with linking when ASL is
present.  A few bits of information to think about:

	Library incompatibility seems to be the base issue.  When ASL is built
with the compile_MS_ASL script, the script copies source files from ASL/solver
into a build directory and then calls nmake with solvers/makefile.vc as the
makefile.  Makefile.vc forces a set of C flags:

  CFLAGS = -nologo -Ot1 -MT

	When I build in debug mode, this causes an immediate link problem for
cbc, because the standard Coin debug build specifies -MTd. An optimised build 
has no trouble at this point, because Coin specifies -MT for the optimised 
build.

	Changing makefile.vc to specify -MTd / -MT as appropriate gets past cbc,
but ultimately both debug and optimised builds founder on
OS/src/OSSolverService.exe, with the message

  amplsolv.lib(fpinitmt.obj) : error LNK2005: __matherr already defined in
    LIBCMT.lib(matherr.obj)
  Creating library OSSolverService.lib and object OSSolverService.exp
  OSSolverService.exe : fatal error LNK1169: one or more multiply defined
    symbols found

	Looking in ASL/solvers/fpinitmt.c, down toward the end of the file
there's the code below, which defines a matherr subroutine.  When I added the
#if 0 ...  endif guard to suppress this code, the build and link works just
dandy.  OS claims it passes all its unit tests, but my guess is that this is not
a conclusive test.  Unfortunately, I'm not an AMPL user and I don't have a good
idea of how and where this function would be used.


#ifdef __MINGW32__
#define matherr _matherr
#endif

#if 0
 matherr_rettype
matherr( struct _exception *e )
{
	switch(e->type) {
	  case _DOMAIN:
	  case _SING:
		errno = set_errno(EDOM);
		break;
	  case _TLOSS:
	  case _OVERFLOW:
		errno = set_errno(ERANGE);
	  }
	return 0;
	}
#endif

	Presumably, at some point in the evolution of Msys and/or MSVS, this
definition was required. Perhaps it's no longer needed? I'm pretty sure I'm 
up-to-date for MSVS / Platform SDK / Msys --- all acquired within the last 
month, due to upgrading my home system.

	What do you folks see?

							Lou