#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,
-
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.
-
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!
- 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