[Coin-ipopt] MUMPS on MinGW?

[Damien Hocking]

Compiling MUMPS on MinGW can be a bit tricky, because with MinGW you're 
mixing compiler types that aren't supported (so far, but the MUMPS devs 
are very helpful).  Having said that, here's the fixes for the tricky 
bits.  I just used Netlib blas for this example.  I'll run through 
everything to explain it, and I've attached a Makefile.inc that will 
work.  There are other minor changes to files in the MUMPS distribution 
that you need to make.

The biggest pain is that although MinGW follows the *Nix conventions, it 
defines the preprocessor symbol _WIN32 as well.  This borks the case of 
exported symbols in the MUMPS code for gfortran, so that symbol needs to 
be undefined as part of the preprocessor options.  I've attached a 
Makefile.inc that has the right preprocessor definitions.  I used the 
sjlj versions of gcc4 for MinGW.  There's no pthreads in the base MinGW 
either, so you need to define WITHOUT_PTHREAD as well in the CDEFS. 
Everything I changed in the makefile has #### at the start and I used 
the gfortran sequential makefile as a starting point.

The MUMPS makefiles aren't quite consistent with their of CDEFS from 
Makefile.inc, and the libseq code doesn't use it when it should.  I've 
attached a fixed makefile, called Makefile.libseq that you should use in 
the libseq directory (save it as Makefile, not Makefile.libseq, like I 
did 10 minutes ago when I tested it again...).

The PORD ordering code needs an include file change for the 
"sys/times.h" problem.  Change it to "sys/time.h" in PORD/include/space.h.

Finally, in dmumps_io_basic.c, there's some code that looks like this 
towards the top:

#ifndef _WIN32
   strcpy(name,dmumps_ooc_file_prefix);
   fd=mkstemp(name);
     if(fd<0){
       ret_code=-99;
       return ret_code;
     }
     else{
       close(fd);
     }

#else
sprintf(name,"%s_%d",dmumps_ooc_file_prefix,((dmumps_files+type)->dmumps_io_current_file_number)+1);
#endif


Comment out or remove all that, and insert the line

sprintf(name,"%s_%d",dmumps_ooc_file_prefix,((dmumps_files+type)->dmumps_io_current_file_number)+1);

MinGW doesn't have a mkstemp function (it tries to use that when you 
undefine _WIN32), and it's not critical, it's just a log file.

That's all you need to get MUMPS going.  Enjoy.

Damien

Andreas Waechter wrote:
> Hi John,
> 
> I have never tried to compile MUMPS under MinGW, mainly because I didn't 
> have a Fortran 90 compiler for Windows (someone recently told me that 
> there is now a gfortran version for MinGW, which is I guess what you are 
> using).
> 
> There is a mailing list for MUMPS, where the developers usually very 
> quickly help out.  I assume that they are also quite interested to have 
> MUMPS working on MinGW, so you might want to give it a try to contact 
> them that way.  There is a link to a "MUMPS Users' mailing list" on the 
> MUMPS website, http://graal.ens-lyon.fr/MUMPS/.
> 
> As for BLAS, you could just download the BLAS sources from netlib and 
> compile them before compiling MUMPS.  Even better, you could try to 
> install the optimized Atlas implementation of BLAS 
> (http://math-atlas.sourceforge.net/) which probably will give you much 
> better performance than the netlib BLAS for large problems.
> 
> If you find out how to compile Ipopt with MUMPS on MinGW, it would be 
> great if you could write down your experience somewhere on the Ipopt 
> wiki page, e.g., at the "Hints and Tricks" page 
> https://projects.coin-or.org/Ipopt/wiki/HintsAndTricks
> 
> Thanks,
> 
> Andreas
> 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: Makefile.libseq
Url: http://list.coin-or.org/pipermail/ipopt/attachments/20071128/ca460c38/attachment.pl 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: Makefile.inc
Url: http://list.coin-or.org/pipermail/ipopt/attachments/20071128/ca460c38/attachment-0001.pl