search

GMLC-TDC / HELICS

Hierarchical Engine for Large-scale Infrastructure Co-Simulation (HELICS)
https://docs.helics.org/en/latest/
BSD 3-Clause "New" or "Revised" License
127 stars 41 forks source link

Can't build Java interface with MSYS2 #1004

Closed temcdrm closed 4 years ago

temcdrm commented 4 years ago

Describe the bug The "make" process stops on libJNIHelics.dll as shown

[100%] Linking C shared library libJNIhelics.dll -- Configuring done -- Generating done -- Build files have been written to: C:/src/HELICS-src/build/interfaces/java/buildjar Building jar file The system cannot find the file specified CMake Error: Generator: execution of make failed. Make command was: nmake /nologo helics && make[2]: *** [interfaces/java/CMakeFiles/JNIhelics.dir/build.make:90: interfaces/java/libJNIhelics.dll] Error 1 make[2]: *** Deleting file 'interfaces/java/libJNIhelics.dll' make[1]: *** [CMakeFiles/Makefile2:1939: interfaces/java/CMakeFiles/JNIhelics.dir/all] Error 2 make: *** [Makefile:141: all] Error 2

What is the expected behavior? Would like to ship some Java agent examples in transactive energy simulation

To Reproduce From the build subdirectory: cmake -G "MSYS Makefiles" -DCMAKE_INSTALL_PREFIX=/usr/local -DBUILD_SHARED_LIBS=ON -DBUILD_PYTHON_INTERFACE=ON -DBUILD_JAVA_INTERFACE=ON -DJAVA_AWT_INCLUDE_PATH=NotNeeded -DHELICS_DISABLE_BOOST=ON -DCMAKE_BUILD_TYPE=Release .. make

Environment (please complete the following information):

Additional context and information This build step used to work in MSYS2. At this time, pacman -Su or a new installation of MSYS2 comes with gcc9. Also, older versions of Java aren't so readily available now.

phlptp commented 4 years ago

I have never tried building The JAVA interface on MSYS2 before, I will look into it.

What is -DJAVA_AWT_INCLUDE_PATH=NotNeeded for?

phlptp commented 4 years ago

Alright I tried it and it seemed to work, but I think it is picking up my windows native jdk rather than an msys2 version of java so that probably isn't a good test.

temcdrm commented 4 years ago

CMake was looking for the Abstract Window Toolkit (AWT), which is not fully present in my headless JDK installation. The -DJAVA_AWT_INCLUDE_PATH=NotNeeded worked around that.

phlptp commented 4 years ago

did you install a java version in msys2 or is using one on your system?

phlptp commented 4 years ago

If that is the case the build system for generates a separate CMAKE build internally. My guess would be it is failing on that internal build since it would be looking for those files on that one as well, but I don't think we pass the CMAKE values through. Though just trying it out looks like there are a few other issues with the java build on MSYS2 as well that probably should be addressed.

temcdrm commented 4 years ago

I've installed Oracle's JDK 11.05 outside of msys2, and then set paths to it inside msys2. FWIW, the FNCS interface to Java builds okay.

phlptp commented 4 years ago

do you know how it works in FNCS? do they use CMAKE or some other process to generate the jar files?

temcdrm commented 4 years ago

Well, FNCS tries to use CMake only for the Java binding, and that only ever worked for me on Linux, and it doesn't any more. I've since switched over to a simple Makefile.

Most of FNCS uses the autotool stuff.

phlptp commented 4 years ago

My suspicion is that it is not passing the correct cache values to the internal build step, which didn't matter if everything was default. Need to do some updates to make that work correctly on MSYS. Probably not going to finish it by today, but hopefully will have something to try out by Monday Morning.

temcdrm commented 4 years ago

Okay, thanks! have a nice weekend

phlptp commented 4 years ago

@temcdrm can you take a look at the java_msys branch and see if that works for you on your system.
It looks like there was a bug inside of the cmake java module on MSYS, still trying to track it down but this branch contains a workaround that works on my system but I would like to make sure it works on yours as well since I think we have different java installs.

temcdrm commented 4 years ago

I get an earlier error on that branch, configured with cmake as above, and still with gcc/g++ 9.2.0. Also please note that I was using master branch before, not develop.

[ 21%] Building CXX object src/helics/core/CMakeFiles/helics_core.dir/CommonCore.cpp.obj C:/src/HELICS-src/src/helics/core/CommonCore.cpp: In member function 'virtual void helics::CommonCore::processPriorityCommand(helics::ActionMessage&&)': C:/src/HELICS-src/src/helics/core/CommonCore.cpp:2133:48: error: 'no_search' was not declared in this scope; did you mean 'bsearch'? 2133 | loopFederates.insert(command.name, no_search, fed); | ^~~~~ | bsearch make[2]: [src/helics/core/CMakeFiles/helics_core.dir/build.make:102: src/helics/core/CMakeFiles/helics_core.dir/CommonCore.cpp.obj] Error 1 make[1]: [CMakeFiles/Makefile2:1319: src/helics/core/CMakeFiles/helics_core.dir/all] Error 2 make: *** [Makefile:141: all] Error 2

phlptp commented 4 years ago

that looks like a submodule version issue. can you run git submodule update and try again

temcdrm commented 4 years ago

It builds now, thanks

phlptp commented 4 years ago

awesome!!, We will merge the fixes shortly and will get into master in the next release.

xcosmos6 commented 4 years ago

that looks like a submodule version issue. can you run git submodule update and try again

I had the same problem "error: 'no_search' was not declared in this scope" when building helics, then "git submodule update" solve the problem. May I ask what does "git submodule update" exactly do here? Thank you very much!

phlptp commented 4 years ago

HELICS uses submodules for some of the supporting libraries. When initially cloning they sync up to the correct version. However if switching branches or pulling, it doesn't necessarily update the linked submodules. Which means if one of the submodules had a breaking change that is fixed in the main code it can cause an error due to the submodules and main code being out of sync.

Sometimes this is caught by internal checks but that is not always possible.

git submodule update syncs all the submodules(external codes) in the local clone of the repo so they are at the version expected by the currently checked out code. In this case that is what has happened. There was a change in one of the submodules that was fixed in develop. But if master was initially cloned then develop or another branch was built. The submodules didn't get synced and needed to be updated to match the branch.

xcosmos6 commented 4 years ago

HELICS uses submodules for some of the supporting libraries. When initially cloning they sync up to the correct version. However if switching branches or pulling, it doesn't necessarily update the linked submodules. Which means if one of the submodules had a breaking change that is fixed in the main code it can cause an error due to the submodules and main code being out of sync.

Sometimes this is caught by internal checks but that is not always possible.

git submodule update syncs all the submodules(external codes) in the local clone of the repo so they are at the version expected by the currently checked out code. In this case that is what has happened. There was a change in one of the submodules that was fixed in develop. But if master was initially cloned then develop or another branch was built. The submodules didn't get synced and needed to be updated to match the branch.

Got it. Thank you very much!