compiling Cactus on Windows

Create issue
Issue #1506 open
Jian Tao created an issue


In the process to create the cactusBSSN benchmark for SPEC, I worked with Mat from PGI(now NVIDIA) to help resolve some compilation issues on Windows. I don't have patches for each one of them, but attemptive solutions could be found in the email below.

These are not critical issues but it would be good to be resolved to help future windows users if there is any.

Regards, Jian

Mathew COLGROVE wrote:

Hi Jian,

I've been working on porting cactusBSSN to Windows. After working through some header file configuration, I encountered several undefined references. I've been able to work around some of them, but a few others I need some help with.

1) "STDOUT_FILENO" and "STDERR_FILENO" in Cactus/main/Warnlevel.c These symbols are found in "unistd.h" which is not available on Windows. I just commented these lines out since I don't think this section is executed. Though, the proper fix would be to define then in the cctk_Config.h file if not "HAVE_UNISTD_H" is not.

The function isatty is defined in unistd.h. A conditional macro will be necessary for that function as well in this case.


if (!isatty (STDOUT_FILENO)) val = "";


2) "hypot" and "copysign" in Cactus/main/Complex.c

Windows does support "hypot" and "copysign", however they spell them "_hypot" and "_copysign". To work around, I created two versions of each macro that use these symbols.

I will probably do the same.

3) "regexec", "regfree", and "regcomp" in Cactus/main/Parameters.c and Cactus/utils/misc.c

Windows does not support these functions. We may be able to integrate a port from glibc into the benchmark but I would rather not. Since previous versions of Cactus did not used these symbols, can we use an older version other these files?

As a matter of fact, Cactus includes files from the src of the GNU C library. You can find them under Your_Cactus/src/gnu.

It is likely that you pre-configured Cactus on a linux box or other systems which provide the library. Cactus will then use the system default instead.

To compiler regex.c getopt.c distributed with Cactus, you need to go to


and set both BUILD_GETOPT BUILD_REGEX to yes.

GNU stuff


This will solve #4 below as well.

4) "getopt_long_only", "optarg", and "optind" in Cactus/main/ProcessCommandLine.c

Again, there is no Windows equivalent for these symbols. We may be able to integrate something from, but I would rather not. Since previous versions of Cactus did not used these symbols, can we use an older version other this file?

5) "gethostname" and "gethostbyname" in Cactus/utils/Network.c

Windows does have these functions but we'd need to link with a DLL which I'd rather not have to do (the user should have the option on how to link). Though, I think we'd be safe to remove these functions.

Yes, the prototypes of gethostname and gethostbyname can be found in winsock2.h, and Cactus knows how to deal with them on Windows.

Network.c : ... #elif defined HAVE_WINSOCK2_H #include <winsock2.h> #endif / HAVE_WINSOCK2_H / ...

If linking DLL will be an issue, I would suggest you keep Util_GetHostName but make it a dummy function since Util_GetHostName serves as the interface to gethostname for Cactus.

Regards, Jian

Keyword: compiling,
Keyword: windows

Comments (6)

  1. Roland Haas
    • removed comment

    Jian, would you be able to package up the required changes in a patch and possibly also provide build instructions for Cactus on Windows? I have never build Cactus on Windows and the last time I had a compiler installed on windows was when Windows 95 was current so am fully unfamiliar with the setup required theses days. I expect things have changed a bit :-) .

  2. Jian Tao reporter
    • removed comment

    I shall hear from Mat soon about the updates. Will try to send patches later on. Let's keep this ticket open as a reminder.

  3. Erik Schnetter
    • changed status to open
    • removed comment

    Were the patches applied? They did not work for me, and they should not have been applied since they hard-coded too many things. For example, the compiler name was hard-coded as "cl".

  4. Frank Löffler
    • removed comment

    Which changes are you talking about? The compiler is set by the option list, and the flesh only guesses if there is no setting. And that guess was changed from 'cl' to 'gcc' if $CC isn't set.

  5. Roland Haas
    • removed comment

    There is a compiler in known architectures. If by "a user" you mean Michele Mottini then no he was not able to compile and proposed a now cygwin known archtictures file. That one compiles Cactus but not the ET. All ExternalLibraries fail since Cactus has LD in ENV which confuses libtool on cygwin. Everything that uses sockets needs to distinguish between have winsock2 and Not have posix sockets since cygwin with gcc provides both. Even with all this fixed it fails at link stage for me on win7 and cygwin64 due to link conflicts between libm and libstdc++.dll . His known architectures file also removes support for any compiler other than gcc which may not be justified (I have admittedly only tried this with gcc though). So this is not fixed.

  6. Log in to comment