Issues when building OpenFAST on Windows under Cygwin #144

evenlund · 2018-06-21T06:20:30Z

I have several issues when following the documentation for building OpenFAST under Cygwin:

In 2.4.1-1 I am unable to use http://www.gtlib.gatech.edu as download site. I am able to access it through a web browser and can find Cygwin there, but the installer complains that it cannot find necessary files there.
I am unable to run "make" directly in any of the folders after installing cygwin with a download site from the list with the packages in 2.4.1-2, rebooting and cloning the OpenFAST repository. There seems to be no makefile in any of the folders.
When trying to run cmake with "FC=gfortran cmake ../" i get the following output. I have installed the openBLAS libary, as described in the docs, and cannot continue after this issue with the build as no makefile is made.

-- The CXX compiler identification is GNU 7.3.0
-- The C compiler identification is GNU 7.3.0
-- The Fortran compiler identification is GNU 7.3.0
-- Check for working CXX compiler: /usr/bin/c++.exe
-- Check for working CXX compiler: /usr/bin/c++.exe -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - failed
-- Detecting CXX compile features
-- Detecting CXX compile features - failed
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - failed
-- Detecting C compile features
-- Detecting C compile features - failed
-- Check for working Fortran compiler: /usr/bin/gfortran.exe
-- Check for working Fortran compiler: /usr/bin/gfortran.exe -- works
-- Detecting Fortran compiler ABI info
-- Detecting Fortran compiler ABI info - failed
-- Checking whether /usr/bin/gfortran.exe supports Fortran 90
-- Checking whether /usr/bin/gfortran.exe supports Fortran 90 -- yes
-- Looking for Fortran sgemm
-- Looking for Fortran sgemm - not found
-- Looking for pthread.h
-- Looking for pthread.h - found
-- Looking for pthread_create
-- Looking for pthread_create - found
-- Found Threads: TRUE
CMake Error at /usr/share/cmake-3.6.2/Modules/FindBLAS.cmake:690 (message):
A required library with BLAS API not found. Please specify library
location.
Call Stack (most recent call first):
CMakeLists.txt:56 (find_package)

nickjohnson13 · 2018-07-02T21:13:06Z

I was having the same problem, but instead of adding the url as "http://www.gtlib.gatech.edu" I added it as "http://www.gtlib.gatech.edu/pub/cygwin/" and it worked.

evenlund · 2018-07-03T07:58:53Z

I tried again with http://www.gtlib.gatech.edu/pub/cygwin/, but there seems to be no difference from using other official mirrors for cygwin. I updated the versions to the newest versions of all necessary packages and rebooted as well.

I think the main problem is issues with the OpenBLAS version of BLAS. Should older version of the cygwin packages be used in order to make the build work?

nickjohnson13 · 2018-07-03T17:27:01Z

I may suggest starting from scratch and following the installation instructions exactly , as this is what I did yesterday and was successful in compiling.

Namely selecting the packages to install:

Select packages necessary for compiling OpenFAST. Choose
binary packages and not the source option.
- Choose Category view, we will be installing packages from
  Devel and Math
- From Devel mark the following packages for installation
  - cmake
  - cmake-doc
  - cmake-gui
  - cygwin-devel
  - gcc-core
  - gcc-fortran
  - gcc-g++
  - git
  - make
  - makedepend
- From Math mark the following packages for installation
  - liblapack-devel
  - libopenblas
- Click Next and accept all additional packages that the setup
  process requests to install to satisfy dependencies
It is recommended that you reboot the machine after installing
Cygwin and all the necessary packages.

evenlund · 2018-07-05T11:53:06Z

I have meticulously followed the steps in the documentation before, and after much back and forth I have concluded that there must be something different with my setup that is causing the problem (see below). The docs still needs to be updated with the correct cygwin mirror web address and the makefile will have to be added to the source if the cmake-step should be skipped.

I have not found out exactly what the cause of the problem was, but I have clues that it might be linked to concurrent installations of cygwin and ubuntu for windows 10. It might also be that I am installing this with administrator privilileges under a non-administrator user and the mixing of users seems to create folders and files that have different owners.

I have though successfully compiled OpenFAST under Cygwin now on a different computer following the instructions. I am able to run openfast -h, but I get an error when running an actual fst file that is working fine with the precompiled version for windows ("Exception: STATUS_STACK_OVERFLOW at rip=."). I have tried transferring this compilation over to the first computer, following the instructions for cmd runs, but get the same error.

I will probably be using the linux-version of OpenFAST now, as this is the only remaining free option available to my knowledge.

stafqjcj · 2018-07-06T08:40:16Z

Did you use a Bladed style dll?

I compiled openfast following the docs and get the same error ("Exception: STATUS_STACK_OVERFLOW at rip=003F96EA5D6...") when running a fst wich worked well under the precompiled version of openfast. The program terminates after running ServoDyn. Is there anything I have to account for using Bladed style dll? Any idea, what I could do to fix this?

evenlund · 2018-07-06T08:44:21Z

Yes, I used the Bladed style dll / DISCON for Hywind OC3. When compiling under linux I have no problem using this library.

Juancuetoarche · 2018-07-08T10:17:03Z

I built Openfast on Windows with Cygwin64 and Cmake but when running any of the regression tests I keep getting the same problem. The last one I've tried, the 5MW_OC4Jckt_DLL_WTurb_WavesIrr_MGrowth test, runs correctly until this message appears: "15999 [] openfast 12504 cygwin_exception::open_stackdumpfile: Dumping stack trace to openfast.exe.stackdump". What am I missing? Anyone knows?

I'll leave a screenshot so you can see in more detail.

Thank you very much in advance.

mylonasc · 2018-08-09T12:30:10Z

This must be a problem with the compilation of ServoDyn in cygwin - I started with a new cygwin, installed the packages as per the instructions (also the proposed repository).

Servodyn seems to run ok on AWT_YFix_WSt.

The error mentioned at "#144 (comment)"
happens also in my case. Does anybody have a debug build? I really don't have the time to invest on chasing it right now and I have a Centos build that just works. I will paste all the relevant information for our future reference

Stacktrace:

Exception: STATUS_STACK_OVERFLOW at rip=003F9D8A5D6
rax=0000000000010608 rbx=00000000FFEF41A0 rcx=00000000FFE03038
rdx=00000000FFEF41B0 rsi=0000000000000001 rdi=00000000FFEF4180
r8 =00000000FFEF4200 r9 =0000000000000000 r10=0000000000000000
r11=0000000000000000 r12=00000000FFEF4190 r13=00000000FFEF4850
r14=00000000FFEF4820 r15=00000000FFEF4810
rbp=00000000FFEF4890 rsp=00000000FFEF4020
program=*** \openfast\build\glue-codes\fast\openfast.exe, pid 3612, thread 
cs=0033 ds=002B es=002B fs=0053 gs=002B ss=002B
Stack trace:
Frame        Function    Args
000FFEF4890  003F9D8A5D6 (003F9ED0556, 000FFEF41A0, 00000000001, 000FFEF4180)
000FFEF4890  00000100608 (000FFEF41A0, 00000000001, 000FFEF4180, 000FFEF4890)
000FFEF4890  000FFEF4250 (00000000001, 000FFEF4180, 000FFEF4890, 000FFEF4190)
000FFEF4890  003F9ED0556 (3FE53BE7C4A9ED34, E1DE6F9E3EAAAAAB, 3FF811111020607A, E5CD4E1D00000000)
000FFEF4890  001015FDDB1 (000FFEF508C, 000FFEF4684, 400C387F33333333, 00000000000)
000FFEF4630  001015908E1 (0060008E800, 00600104710, 0010192FFDC, 000FFEF55CC)
000FFEF55D0  00101591715 (00000000400, 2020202020202020, 001800C5EF0, 000FFEF5AB0)
006000CD670  001015AF294 (000FFEF6BF0, 2020202020202020, 2020202020202020, 000FFEF6BF0)
000FFEF6BE0  0010066D9C1 (000FFF14360, 0010167D460, 001016851B0, 00101681690)
00600049198  00100651AA4 (00000000000, 00101658AB0, 0010165EFD0, 001016751D0)
001016BC480  0010065318F (000FFF24D74, 00000000000, 000FFF24D90, 000FFF251B0)
000FFF24D74  001004DF450 (000FFFFCDF0, 000FFFFCCB0, 00000000000, 00000000000)
000FFFFCCB0  00101644400 (00000000020, 30001010000FF00, 00180047941, 00180046980)
000FFFFCCB0  001800479B2 (00000000000, 00000000000, 00000000000, 00000000000)
00000000000  00180045653 (00000000000, 00000000000, 00000000000, 00000000000)
000FFFFFFF0  00180045704 (00000000000, 00000000000, 00000000000, 00000000000)
End of stack trace (more stack frames may be present)

Some results on what runs and what not that maybe will help others more experienced to figure out what is wrong.

Detailed output from FAST:

for 5MW_Land_BD_DLL_WTurb

 **************************************************************************************************
 OpenFAST

 Copyright (C)  National Renewable Energy Laboratory

 This program is licensed under Apache License Version 2.0 and comes with ABSOLUTELY NO WARRANTY.
 See the "LICENSE" file distributed with this software for details.
 **************************************************************************************************

 OpenFAST-v1.0.0
 Compile Info:
  - Architecture: 64 bit
  - Precision: double
 Execution Info:
  - Date: 08/09/2018
  - Time: 13:53:28+0200

 OpenFAST input file heading:
     FAST Certification Test #26: NREL 5.0 MW Baseline Wind Turbine (Onshore)

 Running ElastoDyn.
 Running BeamDyn.
 Running BeamDyn.
 Running BeamDyn.
 Running AeroDyn.
 Running AirfoilInfo.
 Running BEM.
 Running UnsteadyAero.
 Warning: Turning off Unsteady Aerodynamics because C_nalpha is 0.  BladeNode = 1, Blade = 1
 Warning: Turning off Unsteady Aerodynamics because C_nalpha is 0.  BladeNode = 2, Blade = 1
 Warning: Turning off Unsteady Aerodynamics because C_nalpha is 0.  BladeNode = 3, Blade = 1
 Warning: Turning off Unsteady Aerodynamics because C_nalpha is 0.  BladeNode = 4, Blade = 1
 Warning: Turning off Unsteady Aerodynamics because C_nalpha is 0.  BladeNode = 1, Blade = 2
 Warning: Turning off Unsteady Aerodynamics because C_nalpha is 0.  BladeNode = 2, Blade = 2
 Warning: Turning off Unsteady Aerodynamics because C_nalpha is 0.  BladeNode = 3, Blade = 2
 Warning: Turning off Unsteady Aerodynamics because C_nalpha is 0.  BladeNode = 4, Blade = 2
 Warning: Turning off Unsteady Aerodynamics because C_nalpha is 0.  BladeNode = 1, Blade = 3
 Warning: Turning off Unsteady Aerodynamics because C_nalpha is 0.  BladeNode = 2, Blade = 3
 Warning: Turning off Unsteady Aerodynamics because C_nalpha is 0.  BladeNode = 3, Blade = 3
 Warning: Turning off Unsteady Aerodynamics because C_nalpha is 0.  BladeNode = 4, Blade = 3
 Running InflowWind.

    Reading a 31x31 grid (145 m wide, 17.5 m to 162.5 m above ground) with a characteristic wind
    speed of 12 m/s. This full-field file was generated by TurbSim (v1.06.00, 21-Sep-2012) on
    07-Jan-2014 at 12:50:45.

    Processed 1442 time steps of 20-Hz full-field data (72.05 seconds).
    Running ServoDyn.
    Running ServoDyn Interface for Bladed Controllers.
    Segmentation fault (core dumped)

for WP_VST_ECD :

 **************************************************************************************************
 OpenFAST

 Copyright (C)  National Renewable Energy Laboratory

 This program is licensed under Apache License Version 2.0 and comes with ABSOLUTELY NO WARRANTY.
 See the "LICENSE" file distributed with this software for details.
 **************************************************************************************************

 OpenFAST-v1.0.0
 Compile Info:
  - Architecture: 64 bit
  - Precision: double
 Execution Info:
  - Date: 08/09/2018
  - Time: 14:00:24+0200

 OpenFAST input file heading:
     FAST Certification Test #12: WindPACT 1.5 MW Baseline with many DOFs with VS and VP and ECD
     wind.

 Running ElastoDyn.
 Running AeroDyn.
 Running AirfoilInfo.
 Running BEM.
 Running UnsteadyAero.
 Warning: Turning off Unsteady Aerodynamics because C_nalpha is 0.  BladeNode = 1, Blade = 1
 Warning: Turning off Unsteady Aerodynamics because C_nalpha is 0.  BladeNode = 2, Blade = 1
 Warning: Turning off Unsteady Aerodynamics because C_nalpha is 0.  BladeNode = 1, Blade = 2
 Warning: Turning off Unsteady Aerodynamics because C_nalpha is 0.  BladeNode = 2, Blade = 2
 Warning: Turning off Unsteady Aerodynamics because C_nalpha is 0.  BladeNode = 1, Blade = 3
 Warning: Turning off Unsteady Aerodynamics because C_nalpha is 0.  BladeNode = 2, Blade = 3
 Running InflowWind.
 Running ServoDyn.
Segmentation fault (core dumped)

bjonkman · 2018-08-09T13:54:29Z

My guess (without having looked at the details of the OpenFAST build for cygwin): The code in the Sys*.f90 files that opens DLLs may be incorrect or the build could be using the wrong Sys*.f90 file for Cygwin. These are very system-specific calls.

wuguo2017 · 2018-09-16T12:10:11Z

I had build the openfast successfully by cygwin on Windows10. but when I run the openfast.exe on cmd
by the command:
openfast.exe *.fst

I have the following output:

Running ElastoDyn.
Running AeroDyn.
Running AirfoilInfo.
Running BEM.
Running InflowWind.
6 [] openfast 135820 cygwin_exception::open_stackdumpfile: Dumping stack trace to openfast.exe.stackdump

How to fix this problem?

wuguo2017 · 2018-09-16T12:48:34Z

When I compiling the openfast, the following warning message exits. I doubted that this will lead to stackdump problem when run.
The warning message is:
/cygdrive/d/code/OpenFAST/modules-local/nwtc-library/src/ModMesh.f90:3358:0:

                  ErrMsg = 'MeshExtrapInterp2:'//TRIM(ErrMsg)

warning: ‘__builtin_memset’: specified size 18446744073709551598 exceeds maximum object s
ize 9223372036854775807 [-Wstringop-overflow=]

amoratoc · 2018-11-19T15:19:59Z

I am having similar errors as the above comments. I have compiled openFAST meticulously following the steps in the documentation using CMake and Cygwin.
When running the r-test (openfast/5MW_Land_DLL_WTurb) the following error appears:
3 [] openfast 10872 cygwin_exception: : open_stackdumpfile: Dumping stack trace to openfast.exe.stackdump

If I run the r-test "5MW_OC4Semi_WSt_WavesWN" similar but different error appers as well:
3 [] openfast 17384 cygwin_exception: : open_stackdumpfile: Dumping stack trace to openfast.exe.stackdump

Any solutions would be really appreciated. Thank you very much beforehand!

sth003 · 2018-12-03T21:41:59Z

I also receive a similar error:

openfast 6056 cygwin_exception::open_stackdumpfile: Dumping stack trace to openfast.exe.stackdump

If it is any help the AOC, AWT, ideal beam, and SWRT simulations all seem to run fine, but the WP and 5MW baseline simulations produced the error above. I compiled the appropriate .dll files required for servodyn to run, but don't think those are the issue, since the error only appears when the Aerodyn flag is on (regardless of servodyn flag being on/off).

If I turn off the aerodynamics in the simulation, all runs complete without error.

DavidSchlipf · 2019-01-06T18:01:51Z

I also receive a similar error for OpenFAST-v2.0.0-dirty and Test 18:
Running ServoDyn Interface for Bladed Controllers.
X [] openfast YYYY cygwin_exception::open_stackdumpfile: Dumping stack trace to openfast.exe.stackdump

Maybe this helps to track down the error:

As sth003 mentioned, the aerodynamics seems to be causing this. If used with Aerodyn14 files from FASTv8, it works fine.
If compiling with Visual Studio (Double precision), the original Test 18 terminates normally. However the regression test with 1e-5 fails. Comparing the .out files shows only small numerical differences in some signals. The regression test with 1e-3 works.

DavidSchlipf · 2019-01-06T18:19:44Z

In my case, there is also a large difference in speed between the cygwin compiled version and the one compiled with Visual Studio:

The exe compiled with cygwin needs 1.5 min on my Windows 10 PC to run Test Pull branch #18 with Aerodyn14.
The exe compiled with Visual Studio with double precision needs 37.4 s and single precision 9.2 s.

I would expect more or less double of the time for double precision compared to single precision, but no difference between both double precision versions (cygwin and Visual Studio). Is this normal?

philipalkhoury · 2019-03-08T14:02:06Z

Hello everyone ;

I installed openfast on windows using cmake and cygwin.
I Succeeded in the installation withour errors.
While trying to run the regression test manually 5MW_Land_BD_DLL_WTurb
i am getting the error 👍
0 [ ] openfast 1459 cygwin_exception:: open_stackdumpfile: Dumping stack trace to openfast.exe.stackdump
In plus, Aerodyn V14 cannot run with beamdyn simultaneously ?

I need to understand Any suggestion or solution would be really appreciated.

rafmudaf · 2019-03-20T16:46:52Z

The documentation issue described here is fixed by #262. I will open a new issue for the seg fault and post recent work in this area there.

rafmudaf · 2019-04-12T01:44:03Z

@philipalkhoury I was able to run the regression tests when I changed the optimization setting to -O2 instead of -O3. You can go into the CMakeCache.txt file to do this by modifying the appropriate CMAKE_Fortran_FLAGS_XX for your configuration (don't forget to rerun cmake). Otherwise, use a different build type like this:

cmake .. -DCMAKE_BUILD_TYPE=RelWithDebInfo

In Release mode, the default fortran flags (imposed by cmake) are:

CMAKE_Fortran_FLAGS_RELEASE:STRING=-O3 -DNDEBUG -O3

Whereas in Release with Debug Info mode (RelWithDebInfo), the fortran flags are:

CMAKE_Fortran_FLAGS_RELWITHDEBINFO:STRING=-O2 -g -DNDEBUG

UPDATE: The comment above is incorrect, I mistook MinGW for Cygwin. I'm working on the problems listed here with Cygwin, but I not yet been able to run the regression test cases.

AntoineHEN · 2019-07-31T16:01:16Z

Hello,

Sorry for bothering with this issue again, but I am encountering the same, or a very similar one. I have compiled the latest version of OpenFAST on the dev branch (26/07/2019, version OpenFAST-v2.1.0-164-gacc3f980-dirty) with Cygwin on Windows. It works fine (although very slowly) for most simulations as long as AeroDyn v15 is deactivated. As soon as I turn it on, simulations crash with this message "Segmentation fault (core dumped)". Files named "openfast.exe.stackdump" are left in the build directory when it happens. I do not understand their content but it starts with "Exception: STATUS_STACK_OVERFLOW". The regression tests that use AeroDyn v15 fail for the same reason (the ones using v14 seem to work).

I have successfully recompiled several times with the RelWithDebInfo option as advised above only to find the same error in the end.
[EDIT] I have also tried the "-DCMAKE_BUILD_TYPE=Debug" option without better luck

Is there something I missed to make it work?

Thank you very much in advance for your help.

rafmudaf · 2019-07-31T16:36:23Z

@AntoineHEN the seg fault issue seems to be specific to Cygwin and AeroDyn 15 and it is as yet unsolved. You could try debugging with compiler flags or configuring gdb. I tried the latter but had no luck.

Other options for running OpenFAST on Windows are:

compiling with MinGW
compiling with the windows linux subsystem
download the precompiled binaries on the releases page

bjonkman · 2019-07-31T18:41:07Z

@rafmudaf: the stack overflow message makes me wonder if this is just a problem with the stack size. Have you checked if cmake has specified the stack reserve size for the linker on cygwin? The default stack reserve size is not very large.

rafmudaf · 2019-07-31T20:53:16Z

@bjonkman it looks like thats the problem! CMake was not setting a specific stack size, but I added these lines and at least the first 8 aerodyn15 tests have passed:

MATH(EXPR stack_size "16 * 1024 * 1024") # 16 Mb
set(CMAKE_EXE_LINKER_FLAGS "-Wl,--stack,${stack_size}")

If everything checks out, I'll submit the pull request soon.

AntoineHEN · 2019-08-01T08:00:49Z

Thank you very much @bjonkman and @rafmudaf for your swift answers and investigation!
Waiting for a better solution, I have downloaded the OpenFAST v2.0.0 precompiled binary that seems to work fine (the regression tests at least run, although many results don't check out even at 1e-2, especially the 5MW ones).
I will be interested to try and compile the latest version again once the fix you found is available on GitHub, when you have time.
Thank you again.

rafmudaf · 2019-08-01T22:10:45Z

@AntoineHEN please pull the latest commits from the dev branch and rebuild on Cygwin. You can run only the aerodyn15 test cases with this command:

ctest -L aerodyn15

Its a good idea to delete your existing build directory and start from scratch:

cd <path to openfast>
rm -rf build && mkdir build && cd build
cmake .. -DBUILD_TESTING=ON -DCMAKE_BUILD_TYPE=RELWITHDEBINFO # this speeds up compile time and performance is about the same as RELEASE
make -j4 install
ctest -L aerodyn15

AntoineHEN · 2019-08-06T16:17:26Z

@rafmudaf yes it works! Thank you again for your help and your quick fix of the code.

On another subject, so this might not be the right thread to address it: ctest has never worked for me because there seems to be a problem of paths compatibility between Cygwin and Python (because of the use of "cygdrive/C/ etc" and not just "C:").
Anyhow, I launched the AeroDyn15 regression tests thanks to manualRegressionTest.py and they ran without the stack overflow issue.

Thank you!

rafmudaf · 2019-08-06T17:02:13Z

Great to hear! Yes, we can address the ctest problem in another issue.

vineesh14 · 2019-08-07T16:11:13Z

I am trying to build OpenFAST on Windows with CMake and Cygwin. I get an error everytime it is trying to build the Registry files. I tried it with 'make all', 'make aerodyn_driver', 'make beamdyn_driver' and it always fails at a registry file. A sample error message is below:

input file: /cygdrive/x/FAST/openfast/modules-local/inflowwind/src/IfW_BladedFFWind.txt opening /cygdrive/x/FAST/openfast/modules-local/nwtc-library/src/Registry_NWTC_Library.txt assertion "p >= path" failed: file "/home/corinna/src/cygwin/cygwin-3.0.7/cygwin-3.0.7-1.x86_64/src/newlib-cygwin/winsup/cygwin/path.cc", line 2916, function: int symlink_info::check(char*, const suffix_info*, fs_info&, path_conv_handle&) make[2]: *** [modules-local/inflowwind/CMakeFiles/ifwlib.dir/build.make:63: modules-local/inflowwind/IfW_BladedFFWind_Types.f90] Aborted (core dumped) make[1]: *** [CMakeFiles/Makefile2:241: modules-local/inflowwind/CMakeFiles/ifwlib.dir/all] Error 2 make: *** [Makefile:130: all] Error 2

I installed all the Cygwin packages as listed in the docs. Is there some issue with my Environment Variables?

rafmudaf · 2019-08-07T17:17:18Z

Which branch are you working from? And did you deviate at all from the build instructions?

I haven't seen this error before. If you haven't done this already, I recommend that you remove your build directory, checkout the dev branch, and start from scratch. If that fails again, post the error here.

vineesh14 · 2019-08-07T19:52:30Z

@rafmudaf I was working off the master branch. I switched to dev, and I am facing the same issue. I am following the build process exactly as listed in the docs. I also did a `make clean' then removed the build directory and repeated the process, and the same result. Please see the screendumps in the attached files.

cmake_scrdmp.txt
make_scrdmp.txt

rafmudaf · 2019-08-07T20:00:30Z

Thank you, this is great information. I asked whether you deviated from the installation procedures because I noticed that the failed assertion was related to a symlink and there shouldn't be any of those in the build process:

assertion "p >= path" failed: file "/home/corinna/src/cygwin/cygwin-3.0.7/cygwin-3.0.7-1.x86_64/src/newlib-cygwin/winsup/cygwin/path.cc", line 2916, function: int symlink_info::check(char*, const suffix_info*, fs_info&, path_conv_handle&)

The path.cc file is Cygwin system file: https://github.com/openunix/cygwin/blob/master/winsup/cygwin/path.cc

@bjonkman do you have any clues to offer here?

vineesh14 · 2019-08-07T20:09:29Z

I guessed path.cc is a system file as well, but the location at which it is looking for the file doesn't exist. Hence I was wondering if it is an issue with Environmental variables or some similar.

bjonkman · 2019-08-08T19:39:35Z

I know the Registry code has some special cases for getting the include path names when using cygwin. Maybe that logic assumes something incorrect about cygwin directory names? I'm not sure.

rafmudaf · 2019-08-08T20:34:09Z

@vineesh14 here's the command to run the registry manually for inflowwind:

myopenfast=<your path to>/openfast
$myopenfast/build/modules/openfast-registry/openfast_registry ../modules/inflowwind/src/InflowWind.txt -I  $myopenfast/modules/nwtc-library/src -I  $myopenfast/modules/inflowwind/src

Can you run that and report back?

vineesh14 · 2019-08-14T13:33:12Z

@rafmudaf here's the output from the commands.
registry_scrdmp.txt

rafmudaf added the Type: Documentation label Jun 26, 2018

rafmudaf added the System: MinGW/CygWin label Nov 1, 2018

rafmudaf self-assigned this Nov 30, 2018

rafmudaf added the Status: In progress label Nov 30, 2018

rafmudaf mentioned this issue Mar 19, 2019

A few updates to the documentation #262

Merged

rafmudaf mentioned this issue Apr 12, 2019

Build system: cygwin/mingw #271

Merged

rafmudaf mentioned this issue Apr 19, 2019

How to run FAST v7/v8 and OpenFAST #268

Closed

rafmudaf mentioned this issue Aug 1, 2019

Fix a stack overflow issue in Cygwin #318

Merged

rafmudaf closed this as completed Aug 6, 2019

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Issues when building OpenFAST on Windows under Cygwin #144

Issues when building OpenFAST on Windows under Cygwin #144

evenlund commented Jun 21, 2018

nickjohnson13 commented Jul 2, 2018

evenlund commented Jul 3, 2018 •

edited

Loading

nickjohnson13 commented Jul 3, 2018

evenlund commented Jul 5, 2018

stafqjcj commented Jul 6, 2018

evenlund commented Jul 6, 2018 •

edited

Loading

Juancuetoarche commented Jul 8, 2018 •

edited

Loading

mylonasc commented Aug 9, 2018 •

edited

Loading

bjonkman commented Aug 9, 2018

wuguo2017 commented Sep 16, 2018

wuguo2017 commented Sep 16, 2018

amoratoc commented Nov 19, 2018

sth003 commented Dec 3, 2018

DavidSchlipf commented Jan 6, 2019 •

edited by rafmudaf

Loading

DavidSchlipf commented Jan 6, 2019

philipalkhoury commented Mar 8, 2019

rafmudaf commented Mar 20, 2019

rafmudaf commented Apr 12, 2019 •

edited

Loading

AntoineHEN commented Jul 31, 2019 •

edited

Loading

rafmudaf commented Jul 31, 2019

bjonkman commented Jul 31, 2019

rafmudaf commented Jul 31, 2019

AntoineHEN commented Aug 1, 2019 •

edited

Loading

rafmudaf commented Aug 1, 2019

AntoineHEN commented Aug 6, 2019

rafmudaf commented Aug 6, 2019

vineesh14 commented Aug 7, 2019

rafmudaf commented Aug 7, 2019

vineesh14 commented Aug 7, 2019

rafmudaf commented Aug 7, 2019

vineesh14 commented Aug 7, 2019

bjonkman commented Aug 8, 2019

rafmudaf commented Aug 8, 2019

vineesh14 commented Aug 14, 2019

Issues when building OpenFAST on Windows under Cygwin #144

Issues when building OpenFAST on Windows under Cygwin #144

Comments

evenlund commented Jun 21, 2018

nickjohnson13 commented Jul 2, 2018

evenlund commented Jul 3, 2018 • edited Loading

nickjohnson13 commented Jul 3, 2018

evenlund commented Jul 5, 2018

stafqjcj commented Jul 6, 2018

evenlund commented Jul 6, 2018 • edited Loading

Juancuetoarche commented Jul 8, 2018 • edited Loading

mylonasc commented Aug 9, 2018 • edited Loading

bjonkman commented Aug 9, 2018

wuguo2017 commented Sep 16, 2018

wuguo2017 commented Sep 16, 2018

amoratoc commented Nov 19, 2018

sth003 commented Dec 3, 2018

DavidSchlipf commented Jan 6, 2019 • edited by rafmudaf Loading

DavidSchlipf commented Jan 6, 2019

philipalkhoury commented Mar 8, 2019

rafmudaf commented Mar 20, 2019

rafmudaf commented Apr 12, 2019 • edited Loading

AntoineHEN commented Jul 31, 2019 • edited Loading

rafmudaf commented Jul 31, 2019

bjonkman commented Jul 31, 2019

rafmudaf commented Jul 31, 2019

AntoineHEN commented Aug 1, 2019 • edited Loading

rafmudaf commented Aug 1, 2019

AntoineHEN commented Aug 6, 2019

rafmudaf commented Aug 6, 2019

vineesh14 commented Aug 7, 2019

rafmudaf commented Aug 7, 2019

vineesh14 commented Aug 7, 2019

rafmudaf commented Aug 7, 2019

vineesh14 commented Aug 7, 2019

bjonkman commented Aug 8, 2019

rafmudaf commented Aug 8, 2019

vineesh14 commented Aug 14, 2019

evenlund commented Jul 3, 2018 •

edited

Loading

evenlund commented Jul 6, 2018 •

edited

Loading

Juancuetoarche commented Jul 8, 2018 •

edited

Loading

mylonasc commented Aug 9, 2018 •

edited

Loading

DavidSchlipf commented Jan 6, 2019 •

edited by rafmudaf

Loading

rafmudaf commented Apr 12, 2019 •

edited

Loading

AntoineHEN commented Jul 31, 2019 •

edited

Loading

AntoineHEN commented Aug 1, 2019 •

edited

Loading