Generating compiled library files via Github Actions

[jtgrasb]

After some efforts with the pre-compiled releases (#285), I am working on using cmake to generate the library files in GitHub Actions. This is needed instead of using the pre-compiled releases to avoid requiring vtk (which WEC-Sim is not set up to interface with), so I set -DUSE_VTK=OFF.

Unfortunately, the .so files that are generated seem to require GLIBC 2.29 while the Linux machine (shared) I am trying to test it on only has GLIBC 2.28. Do you know what in MoorDyn is triggering the requirement for GLIBC 2.29 and if there's any way to turn the requirement off?

[sanguinariojoe]

It sound like matlab messing up. Matlab has its own compiler, which is actually a gcc. I suppose it should be possible to instruct matlab mex to use the system compiler, but I have not investigated that yet. I indeed disabled matlab testing because of that. Might that be a possibility?

…

On Wed, 26 Mar 2025, 18:13 jtgrasb, ***@***.***> wrote: After some efforts with the pre-compiled releases (#285 <#285>), I am working on using cmake to generate the library files in GitHub Actions. This is needed instead of using the pre-compiled releases to avoid requiring vtk (which WEC-Sim is not set up to interface with), so I set -DUSE_VTK=OFF. Unfortunately, the .so files that are generated seem to require GLIBC 2.29 while the Linux machine (shared) I am trying to test it on only has GLIBC 2.28. Do you know what in MoorDyn is triggering the requirement for GLIBC 2.29 and if there's any way to turn the requirement off? — Reply to this email directly, view it on GitHub <#300>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAMXKKD7WVZS5WVEQG66JKT2WLN23AVCNFSM6AAAAABZ24OA7GVHI2DSMVQWIX3LMV43ASLTON2WKOZSHE2TAMZQGEYDEMY> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***> [image: jtgrasb]*jtgrasb* created an issue (FloatingArrayDesign/MoorDyn#300) <#300> After some efforts with the pre-compiled releases (#285 <#285>), I am working on using cmake to generate the library files in GitHub Actions. This is needed instead of using the pre-compiled releases to avoid requiring vtk (which WEC-Sim is not set up to interface with), so I set -DUSE_VTK=OFF. Unfortunately, the .so files that are generated seem to require GLIBC 2.29 while the Linux machine (shared) I am trying to test it on only has GLIBC 2.28. Do you know what in MoorDyn is triggering the requirement for GLIBC 2.29 and if there's any way to turn the requirement off? — Reply to this email directly, view it on GitHub <#300>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAMXKKD7WVZS5WVEQG66JKT2WLN23AVCNFSM6AAAAABZ24OA7GVHI2DSMVQWIX3LMV43ASLTON2WKOZSHE2TAMZQGEYDEMY> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[jtgrasb]

I am not sure I fully understand your suggestion. I am using the loadlibrary() function to load in the compiled .so file. It does not seem like there is an option to instruct MATLAB on which compiler to use.

[RyanDavies19]

@jtgrasb Have you disabled all the wrappers when you are compiling? (-DMATLAB_WRAPPER=OFF, -DPYTHON_WRAPPER=OFF, -DFORTRAN_WRAPPER=OFF, etc.) You can quickly check by running ccmake .. from the build folder.

@sanguinariojoe for context with the WEC-Sim coupling we are not using the MATLAB wrappers because the WEC-Sim team wanted to provide precompiled binaries that are compatible with multiple MATLAB versions, and the mex files as they are set up now require the user to compile MoorDyn from source in order for them to be compatible with their local MATLAB version.

[jtgrasb]

I am using the compileLibraries.yml file from the PR here to compile the libraries. One thing that seems to be missing is -DMATLAB_WRAPPER=OFF. I'll try adding this and see if it makes a difference.

[sanguinariojoe]

Understood! Well, I did not nail the shot, but I really think that is indeed the problem. I hope that disabling the wrapper it works just fine

…

On Tue, 22 Apr 2025, 17:29 jtgrasb, ***@***.***> wrote: I am using the compileLibraries.yml file from the PR here <WEC-Sim/MoorDyn#15> to compile the libraries. One thing that seems to be missing is -DMATLAB_WRAPPER=OFF. I'll try adding this and see if it makes a difference. — Reply to this email directly, view it on GitHub <#300 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAMXKKHKM7RCATZB647GKAL22ZN7DAVCNFSM6AAAAABZ24OA7GVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDQMRRG4YDKNZXGA> . You are receiving this because you were mentioned.Message ID: ***@***.***> *jtgrasb* left a comment (FloatingArrayDesign/MoorDyn#300) <#300 (comment)> I am using the compileLibraries.yml file from the PR here <WEC-Sim/MoorDyn#15> to compile the libraries. One thing that seems to be missing is -DMATLAB_WRAPPER=OFF. I'll try adding this and see if it makes a difference. — Reply to this email directly, view it on GitHub <#300 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAMXKKHKM7RCATZB647GKAL22ZN7DAVCNFSM6AAAAABZ24OA7GVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDQMRRG4YDKNZXGA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[jtgrasb]

I am using the compileLibraries.yml file from the PR here to compile the libraries. One thing that seems to be missing is -DMATLAB_WRAPPER=OFF. I'll try adding this and see if it makes a difference.

I tried with the MATLAB wrapper off and this did not resolve the issue. Unfortunately, it seems because GitHub Actions uses a minimum ubuntu version of 20.04 (which has GLIBC 2.31) and I am unable to update the GLIBC on my local Linux machine as it is shared, it may not work. Instead, I added documentation to recommend our users to compile the MoorDyn code locally to generate the necessary .so files. This is an okay solution for now, but if you are able to determine what is causing the GLIBC 2.29 requirement, please let us know.

[sanguinariojoe]

This is a classic issue on Linux, GLIBC is backward compatible (anything compiled with an older version of GLIBC will work on modern systems), but not forward compatible (if you compile something on a new system, it wont work on old ones). That's why on Python they have created the famous manylinux and musllinux containers.

Look for instance the package
moordyn-2.4.0-cp313-cp313-manylinux_2_17_x86_64.manylinux2014_x86_64.whl here. It says that uses glibc 2.17+ (like 10 years old?).

I think I already asked this, but have you tried the libraries deployed on the python wheels? The Python wheels are just zip files, so you can uncompress them and find the moordyn library:

• moordyn.libs folder for linux
• moordyn/.dylibs folder for MacOs
• moordyn-2.4.0.data/platlib folder for Windows

The version of Python (Cp313, Cp312, ...) does not matter actually, since the MoorDyn library is built just once per arch.

[jtgrasb]

@sanguinariojoe Thanks for the suggestions. I will look into the package you've linked and how it was compiled. If I can replicate that in Github actions on the WEC-Sim/MoorDyn repo, that should resolve our issues.

I believe the libraries deployed on the python wheels will not work for us because WEC-Sim is not compatible with vtk, so we need to compile our own with -DUSE_VTK=OFF.

[sanguinariojoe]

Vtk is statically linked on those libs, so unless you have sort of a hard collision (which I cannot even figure out how, because the symbols are not exported), it should not matter at all, i.e. the lib is working even if you do not have vtk

…

On Wed, 7 May 2025, 00:45 jtgrasb, ***@***.***> wrote: *jtgrasb* left a comment (FloatingArrayDesign/MoorDyn#300) <#300 (comment)> @sanguinariojoe <https://github.com/sanguinariojoe> Thanks for the suggestions. I will look into the package you've linked and how it was compiled. If I can replicate that in Github actions on the WEC-Sim/MoorDyn repo, that should resolve our issues. I believe the libraries deployed on the python wheels will not work for us because WEC-Sim is not compatible with vtk, so we need to compile our own with -DUSE_VTK=OFF. — Reply to this email directly, view it on GitHub <#300 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAMXKKDSDCVH6PZSQ6KJT5L25E3O5AVCNFSM6AAAAABZ24OA7GVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDQNJWGM3TMMJQG4> . You are receiving this because you were mentioned.Message ID: ***@***.***>