Skip to content

#912 Dune on MinGW

Metadata

Property Value
Reported by Bernd Flemisch (bernd@iws.uni-stuttgart.de)
Reported at May 4, 2011 08:39
Type Bug Report
Version 2.0
Operating System Unspecified / All
Last edited by Christoph Grüninger (gruenich@iws.uni-stuttgart.de)
Last edited at Jun 26, 2015 11:49
Closed by Christoph Grüninger (gruenich@iws.uni-stuttgart.de)
Closed at Jun 26, 2015 11:49
Closed in version Unknown
Resolution Fixed
Comment The MinGW patches were applied a long time ago. With dune-grids's 66219680… the tmpnam issue is fixed for Unices.

Description

Dear Dune,

below is a discussion from the mailing list, which was encouraged to be filed as a bug report.

The point is that building Dune 2.0 on MinGW almost works. There are two issues,

  1. The non-presence of mathematical constants like M_PI in MinGW's cmath. This initiated a separate discussion for providing Dune's own mathematical constants.

  2. The non-presence of the functions 'close' in <unistd.h> and 'mkstemp' in <stdlib.h>. More details are below.

On Wed, May 04, 2011 at 10:08:50AM +0200, Martin Nolte wrote:

Hi Bernd,

some of the errors were easy to fix. The missing functions mkstemp and close are slightly more problematic. It seems the header <unistd.h> is present on MinGW but does not contain close. The function mkstemp should actually be in <stdlib.h>, but does not seem present either. I guess we simply have to construct the filename ourselves using, e.g., rand() -- sigh. actually there is a portable alternative of mkstemp, but I don't remeber it. When we were on the train with Olaf, we found something in the gcc docs.

Perhaps Olaf can enlight us, or even better, perhaps he still has the patch, he prepared the last time.

Christian

Maybe you just open a bug report on this, so we don't forget?

Best,

Martin

On 05/04/2011 09:39 AM, Bernd Flemisch wrote:

Dear Dune,

including cmath does not help. cmath is found, but M_PI is still undefined, so Bard's comment seems to be appropriate. I grepped for M_PI, it appears only in dgfprojectionblock.hh plus in some tests in dune-grid and dune-istl.

Compiling the temporaryFileName method gives several errors: dgfparser.cc:1213:26: error: invalid operands of types 'const char [2]' and 'con st char [2]' to binary 'operator+' dgfparser.cc:1218:38: error: 'mkstemp' was not declared in this scope dgfparser.cc:1221:34: error: 'P_tmpdir' was not declared in this scope dgfparser.cc:1228:15: error: 'close' was not declared in this scope While I guess that the first one can be easily fixed, the other ones seem to be more serious. There is some discussion on the MinGW mailing lists where they apparently fix this, but it does not look that easy: http://www.mail-archive.com/bug-gnulib@gnu.org/msg17727.html

Kind regards Bernd

On Wed, 04 May 2011 08:44:52 +0200 Oliver Sander sander@mi.fu-berlin.de wrote:

Hi all!

  1. what exactly is the error in the temroraryFileName method? I remember that after the last Dune meeting Olaf Ippisch spent the time on the train ride properly fixing this issue. However nobody ever managed to make him actually submit the patch to the public.

-- Oliver

Best Andreas

On 03/05/11 17:57, Bernd Flemisch wrote:

Dear Dune,

I am not sure whether I tell you something new and/or interesting, but since I did not find this on the list, I thought I just share it.

I tried to install Dune 2.0 under Windows on top of MinGW, http://www.mingw.org/. And it worked almost without modifications. In particular, I had to

  • define the constant M_PI in dgfprojectionblock.cc line 113.

  • change the temroraryFileName method in dgfparser.cc line 1204 (I simply return an empty string and comment out the rest).

All core modules of the 2.0 release compile. Only the test in dune-istl and the finiteelements test of the dune-grid-howto fail due to missing headers sys/timer.h and sys/resource.h. The other grid-howto programs seem to run correctly and produce meaningful vtk output.

I did not use any external packages.

Kind regards Bernd