Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

HELICS autobuild fails on Linux #13

Open
nightlark opened this issue Apr 28, 2018 · 11 comments
Open

HELICS autobuild fails on Linux #13

nightlark opened this issue Apr 28, 2018 · 11 comments

Comments

@nightlark
Copy link
Collaborator

I tried enabling autobuild for HELICS, and there were a number of errors. It would be good to go over the HELICS and ZMQ find/autobuild scripts to make sure that variable names getting set are correct; different configurations of autobuilding/finding can result in different variables being set.

@nightlark nightlark added the bug label Apr 28, 2018
@activeshadow
Copy link

@nightlark how exactly do you enable HELICS? The HELICS-Tutorial README mentions compiling from the cmake_update branch... does anything else special need to be done? Enabling ZMQ perhaps?

As an FYI, when I tried building the cmake_update branch I get the following errors:

../src/griddyn/libgriddyn.a(idaInterface.cpp.o): In function `griddyn::solvers::idaInterface::initialize(TimeRepresentation<count_time<9, long> >)':
idaInterface.cpp:(.text+0x2b0f): undefined reference to `IDADlsSetLinearSolver'
idaInterface.cpp:(.text+0x2b96): undefined reference to `IDADlsSetJacFn'
../src/griddyn/libgriddyn.a(kinsolInterface.cpp.o): In function `griddyn::solvers::kinsolInterface::initialize(TimeRepresentation<count_time<9, long> >)':
kinsolInterface.cpp:(.text+0x1471): undefined reference to `KINDlsSetLinearSolver'
kinsolInterface.cpp:(.text+0x14f8): undefined reference to `KINDlsSetJacFn'
../src/griddyn/libgriddyn.a(cvodeInterface.cpp.o): In function `griddyn::solvers::cvodeInterface::initialize(TimeRepresentation<count_time<9, long> >)':
cvodeInterface.cpp:(.text+0x2a94): undefined reference to `CVDlsSetLinearSolver'
cvodeInterface.cpp:(.text+0x2b1b): undefined reference to `CVDlsSetJacFn'
../src/griddyn/libgriddyn.a(arkodeInterface.cpp.o): In function `griddyn::solvers::arkodeInterface::initialize(TimeRepresentation<count_time<9, long> >)':
arkodeInterface.cpp:(.text+0x2611): undefined reference to `ARKDlsSetLinearSolver'
arkodeInterface.cpp:(.text+0x2698): undefined reference to `ARKDlsSetJacFn'
collect2: error: ld returned 1 exit status
test/CMakeFiles/testLibrary.dir/build.make:624: recipe for target 'test/testLibrary' failed
make[2]: *** [test/testLibrary] Error 1
CMakeFiles/Makefile2:1685: recipe for target 'test/CMakeFiles/testLibrary.dir/all' failed
make[1]: *** [test/CMakeFiles/testLibrary.dir/all] Error 2

@phlptp
Copy link
Collaborator

phlptp commented Sep 7, 2018

To build with HELICS support you need to enable the HELICS_EXECUTABLE option. ZMQ should automatically come along with that option when enabled.

Which OS version were you building on where you go the errors? It looks like sundials is not being linked properly for some reason.

@nightlark
Copy link
Collaborator Author

nightlark commented Sep 7, 2018

If you don't already have a copy of HELICS built that you want to use, there's also an AUTOBUILD_HELICS option that can be set to ON to have cmake download and build a copy as part of the configure step. The HELICS_INSTALL_PATH option can be used to tell cmake where an existing install of HELICS is located.

@activeshadow
Copy link

Ubuntu 18.04 (using Docker)

I created a build directory in the GridDyn root, then simply ran cmake .. && make -j8. Next time I'll add the -DHELICS_EXECUTABLE=ON option to cmake.

Sundials is getting automatically downloaded, but I can't tell if it's getting compiled or linked to as part of the build.

@activeshadow
Copy link

@phlptp any chance you have some ideas here?

@phlptp
Copy link
Collaborator

phlptp commented Sep 11, 2018

I just tried

cmake .. && make -j8

on a virtual machine with Ubuntu 18.04, it by default used gcc 7.3 and it built without errors.

One possibility is not having suitesparse installed, that might prevent sundials from building built completely. GridDyn can run without it but you might need some other options enabled and it isn't a common use case so I am not sure right now how it would play out in this environment.

sudo apt-get libsuitesparse-dev

and I am not completely sure how that would show up just using cmake .. I guess I usually just use the cmake-gui or ccmake to configure some other options.

@activeshadow
Copy link

Thanks @phlptp, that's helpful! I'll let you know how my testing goes.

@activeshadow
Copy link

@phlptp installing libsuitesparse-dev got me past the previous build errors, but now I'm getting new ones.

/usr/bin/x86_64-linux-gnu-ld: ../fmi/libfmiGDLibrary.a(fmiImport.cpp.o): undefined reference to symbol 'dlclose@@GLIBC_2.2.5'
/usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu/libdl.so: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status

One documented way of fixing this issue is to ensure the dl library is linked when compiling (ie. LIBS=-ldl). I tried setting this when running make but it didn't make a difference and I'm not familiar enough w/ cmake to know how to ensure it's set. I didn't see an option for it in the cmake curses GUI.

Speaking of... below is a screenshot of the cmake curses GUI. Looking at the bottom, I'm curious if SuiteSparse_DIR-NOTFOUND is an issue since SUNDIALS_KLU_INCLUDE_PATH seems to have found it. I can change it via the curses GUI, but it doesn't let me regenerate the make configs after I do.

image

@phlptp
Copy link
Collaborator

phlptp commented Sep 11, 2018

I have never encountered that particular issue, but if I had to guess I would guess that boost was not installed completely. Based on the location in the fmi library, The FMIGD library, which you could turn off if you didn't need that, uses the boost dll library, which is header only, but it wouldn't surprise me if it had dependencies on Linux. I am just guessing here as I have not encountered that error or any issue with it before. But I also haven't spent that much dealing with FMI stuff on a linux platform either.

Now as for Sundials if Suitesparse wasn't available on the first build you may have to change the FORCE_SUNDIALS_REBUILD to ON to get it to build with all the KLU linkages, otherwise GridDyn will probably be kind of slow.

@activeshadow
Copy link

@phlptp that helped a lot. The trick turned out to be requiring libdl for the FMI library. I edited the target_link_libraries directive in src/fmi/CMakeLists.txt as follows.

diff --git a/src/fmi/CMakeLists.txt b/src/fmi/CMakeLists.txt
index 63f35f7..4ffd693 100644
--- a/src/fmi/CMakeLists.txt
+++ b/src/fmi/CMakeLists.txt
@@ -78,7 +78,7 @@ source_group("FMUImport" FILES ${fmiImport_sources} ${fmiImport_headers})
 
 set_target_properties(fmiGDLibrary PROPERTIES FOLDER fmi)
 
-target_link_libraries(fmiGDLibrary griddyn formatInterpreter)
+target_link_libraries(fmiGDLibrary griddyn formatInterpreter ${CMAKE_DL_LIBS})
 
 install(
     TARGETS fmiGDLibrary

Thanks again for the help!

@phlptp
Copy link
Collaborator

phlptp commented Sep 12, 2018

I will make the change in the cmake files.
Thanks! Glad you were able to get it working.

@phlptp phlptp removed the bug label Nov 20, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants