04.10.06

OpenFOAM-1.3 Cygwin port posted.

Posted in Computational Fluid Dynamics at 11:42 pm by Brooks

After a couple of weeks of work (in and among the other things I was doing), I’ve finished a releasable version of the OpenFOAM-1.3 Cygwin port. I’ve stuck it all in a source .tar.gz file and a compiled-binaries .tar.gz file, and updated the openfoam-cygwin page with links and updated instructions and things. There’s also a compiled-binary version of gcc 4.1.0 up there to go with it, for people who’d rather not compile their own – theoretically, this time around, OpenFOAM shouldn’t need a specially-configured version like it did of 4.0.2 (to get around a gcc bug), but I couldn’t find any binaries already online to copy, so I had to make my own again.

The basics of the port were pretty much the same as last time. There are a couple of key problems to work around to get OpenFOAM to compile on Cygwin. First, it’s written for a case-sensitive filesystem, and has files named “Vector.H” and “vector.H” in the same directory, and suchlike. This clashes when one tries to unpack the source distribution on a case-insensitive filesystem, and then when one goes to compile it, the #include lines in the source files pull in the system’s “vector.h” file instead of either of them. Fixing this is a tedious but trivial matter of renaming all the relevant files, and fixing all the #include lines. Someday I’ll write a script for it, but this time I did it by hand with the disk-search-and-replace in my text editor.

The more interesting problem involves how dynamically-linked libraries are compiled and linked on Windows versus Unix and Linux. OpenFOAM is, functionally, a big set of libraries that get linked into application-specific (and often user-written) wrapper programs. Most of the core functionality is in a libOpenFOAM library, although the parallel-processing parts are off in a libPstream library. This allows for different parallel implementations to be used depending on which of various libPstream libraries is actually used at runtime, while having only one version of the libOpenFOAM library. Unfortunately, this is written with a bit of a circular dependence; libPstream uses a lot of data types defined in libOpenFOAM, while libOpenFOAM needs to link to libPstream.

On Unix and Linux systems, this doesn’t actually present any difficulties; one simply includes the relevant header files when compiling the two libraries, and then all of the class methods from libOpenFOAM and the parallel functions from libPstream get resolved when the final wrapper code is compiled and the two libraries are both linked in.

It seems that this fundamentally doesn’t work on Windows, however, because (as I understand it), a dynamically-linked library on Windows cannot have unresolved symbols. All of those functions need to be resolved at compile-time, even if they get resolved differently at runtime. And so we can’t compile libPstream first because it needs to link to libOpenFOAM at compile-time, and we can’t compile libOpenFOAM first because it needs to link to libPstream at compile-time. This is a bit sticky.

The solution to this is a bit of modification to the OpenFOAM make scripts that Petr Vita created and posted to the OpenFOAM forums earlier this year. I don’t quite understand the details yet, but he’s written something that allows the make script for one library to “import” the source files from another library and include them, and thus the compilation of libOpenFOAM can reference the relevant libPstream functions that way, before libPstream is compiled. Then, once that’s taken care of, we can compile libPstream in the usual way by linking to the libOpenFOAM library, and all is well.

This time around, that seemed to work a lot better than it did in OpenFOAM-1.2 – or perhaps I simply had better luck with the compiler. In any case, in OpenFOAM-1.2, it didn’t work to import the (only three) libPstream files into libOpenFOAM, and instead Petr had to do things the other way around, which involved dozens of libOpenFOAM files getting imported. And then the libOpenFOAM files had to be imported into another library as well, which should have compiled fine without them, but apparently didn’t. This time around that one worked just as it should with just a link to the libOpenFOAM library, so now I’m wondering if perhaps something was just mixed up on Petr’s computer that day.

The rest of the port involved a few other things that shook out because of things that I’m guessing were the result of this Windows pickiness. There were a couple of cases where an additional #include was needed in a source file to get the resulting library to link, including one case where the relevant function prototypes weren’t actually in a header file at all. And then, there were a vast pile of cases where additional libraries needed to be given to the linker explicitly – presumably as a result of the fact that on Linux the link process didn’t complain if a needed library was omitted, and there weren’t any runtime failures if the library got referenced by the relevant applications somehow – so there was a bit of trial and error fixing those. Someday I should look up the relevant gcc options to tell the linker not to give me ten thousand (literally; Windows gives me a maximum 9999-line scrollback buffer, and it got overflowed) lines of errors, but instead stop reporting after the first five or so.

But, in any case, that’s all done, and I’ve uploaded the files and posted an announcement post on the discussion board. Now to see if it works for anyone else!

Permalink