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.

Sign up for GitHub

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

Jump to bottom

Binaries compiled with shared libraries are not properly installed #430

Closed
CallumG-Ed opened this issue Mar 27, 2020 · 18 comments
Closed

Binaries compiled with shared libraries are not properly installed #430

CallumG-Ed opened this issue Mar 27, 2020 · 18 comments
Assignees
@rafmudaf
Labels
System: CMake Type: Bug

Comments

@CallumG-Ed
Copy link

CallumG-Ed commented Mar 27, 2020 •
edited
Loading

Hello Everyone,

My aim is to run a very simple single turbine example in a non-turbulent constant velocity (across the rotor) flow.

I run linux Ubuntu 18.04 so I built OpenFAST with the flag "DBUILD_OPENFAST_CPP_API:BOOL=ON"

I have navigated to /openfast/glue-codes/openfast-cpp/src and attempted to run the example case "FAST_Prog.cpp" by downloading the iDriver into the directory and envoking comand mpiexec -np openfastcpp as per the manual. This returns an error "mpiexec was unable to find the specified executable file..."

Therefore I edit "openfastcpp" to the full path ie: mpiexec -np /openfast/install/bin/openfastcpp . This returns an error: "error while loading shared libraries: libopenfastcpplib.so: cannot open shared object file: No such file or directory"

So I have a few questions:

  1. What is the protocol to setting up a simulation? Was it incorrect to download the iDriver file into the src directory and attempt to run from there? (It didn't feel right).

  2. How do I overcome the error I am now presented with.

  3. Is there a way of running a module, say aerodyn, independently on linux systems?

Any and all help gratefully recieved!

Cheers
Callum
@madsmammen
Copy link

Hi CallumG
Regarding 3) running Aerodyn as standalone on linux.
I have been running Aerodyn via the via 'aerodyn_driver' located in 'install/bin' directory on Ubuntu 18.04 LTS. If trhis is a answer to You, I can attach the input files - to be honest it took me quite some time to find and get the input files right.

Regards Mads

@CallumG-Ed
Copy link
Author

Hi Mads

thanks for taking the time to respond! Yes that would be really useful if you could share example input files. Do you run them from the same diretory as the executable file?

If you could give me some advice on how you setup your case in what directory etc and the command line syntax that would really help me out. Thanks again for your time!

Cheers
Callum

@madsmammen
Copy link

madsmammen commented Mar 28, 2020 via email

@CallumG-Ed
Copy link
Author

Hi Mads,

thats really good of you to share your files. I don't see an attchchment to your post? Have you perhaps forgot to attch the tar file?

Cheers
Callum

@madsmammen
Copy link

madsmammen commented Mar 31, 2020 via email

@CallumG-Ed
Copy link
Author

CallumG-Ed commented Mar 31, 2020 •
edited
Loading

Hi again Mads,

I don't think it's working, I'm not sure whether you can actually attach zip files. But I have downloaded all the required inputs here, and after navigating to the directory with these in, I envoke in the commad line:

$HOME/OpenFAST/openfast/install/bin/aerodyn_driver driver.dvr

I get an error:

error while loading shared libraries: libaerodynlib.so: cannot open shared object file: No such file or directory

Or if I try to execute aerodyn_driver with:

. $HOME/OpenFAST/openfast/install/bin/aerodyn_driver driver.dvr

I get error:

bash: .:$HOME/OpenFAST/openfast/install/bin/aerodyn_driver: cannot execute binary file

I'm I missing something fundimental in how I'm trying to run the thing?

Would you have any thoughts on why this doesn't work? I've checked that the .so file is in /install/lib and the reg tests ran when I did the install here #384.

As always any support on this issue would be really appreciated.

Cheers
Callum

@CallumG-Ed
Copy link
Author

Update

After setting up case as per this, I envoke the executable from the build directory instead:

$HOME/OpenFAST/openfast/build/modules/aerodyn/aerodyn_driver driver.dvr

and now I get aerodyn to run but with error:

Init_AeroDyn:AD_Init:ReadInputFiles:ReadPrimaryFile:Invalid numerical input for file "./input.dat" occurred while trying to read NumAFfiles. AeroDyn Driver encountered simulation error level: FATAL ERROR

the NumAFfiles is 10 and they're all in the correct place?

Any ideas welcome!

@andrew-platt
Copy link
Collaborator

andrew-platt commented Mar 31, 2020 •
edited
Loading

There is a line missing for the AFTabMod (recently added to the dev branch). Here is an example of the AD15 input file compatible with the dev branch: https://github.com/OpenFAST/r-test/blob/4ac9baa653d45a1f8a4e1e30617e2f541eab7457/glue-codes/openfast/5MW_Land_DLL_WTurb/NRELOffshrBsline5MW_Onshore_AeroDyn15.dat

Our apologies for not providing working examples for the aerodyn_driver. We are expecting to add driver level regression tests for AeroDyn15 within the next month. Once those have been added to the regression tests, we will keep them synchronized with all feature enhancements.

In regards to the location of the aerodyn_driver, if you run make install, it will install the driver into the install/bin/ folder.

@madsmammen
Copy link

madsmammen commented Mar 31, 2020 via email

@madsmammen
Copy link

madsmammen commented Mar 31, 2020 via email

@CallumG-Ed
Copy link
Author

Hi Mads and Andrew,

Thanks both for the comments and help!

Rightfully so, adding in the "AFTabMod" line did solve the run issue and yes as you say Mads the 'Test01_UAE_AeroDyn_blade.dat' needed changing to 'blade.dat'. I now have it running, which is brilliant!

However, Andrew I did in fact 'make install' (I outline my complete proceedure in the first comment in #384) but when I attempt to execute on the path:

$HOME/OpenFAST/openfast/install/bin/aerodyn_driver driver.dvr

I get error

/home/callum/OpenFAST/openfast/install/bin/aerodyn_driver: error while loading shared libraries: libaerodynlib.so: cannot open shared object file: No such file or directory

It's not the end of the world, but maybe a bug?

Thanks both for all your help, I really appreciate your time and effort!

All the best,
Callum

@madsmammen
Copy link

madsmammen commented Apr 1, 2020 via email

@CallumG-Ed
Copy link
Author

Hi Mads,

yes, I would like to know why in my case the executable can't find the library on the install path?

Like I say its not the end of the world as I can call it from the build path, but it does seem strange. Perhaps it's something Andy might have an idea on.

All the best,
Callum

@andrew-platt
Copy link
Collaborator

andrew-platt commented Apr 1, 2020 •
edited
Loading

Hi Callum,

Is the location of the libaerodynlib.so in your PATH? You might need to do something like export PATH=<path to diriectory with lib>:$PATH so that it can be found.

@rafmudaf, do you have any other ideas on the library loading issue a few comments up?

Cheers,
Andy

@rafmudaf
Copy link
Collaborator

rafmudaf commented Apr 1, 2020

My guess is something changed in the build settings (for example, in #384 there is no flag for building shared libraries) and now the binaries are out of sync. Somehow the AeroDyn Driver is expecting a .so but that library isn't compiled or isn't installed.

@CallumG-Ed try running the driver from the build directory at openfast/build/modules/aerodyn_driver. If that runs, then it compiled fine but something didn't copy over to the install location.

@CallumG-Ed
Copy link
Author

Hi Andy/Raf,

The driver does run on the openfast/build/modules/aerodyn_driver path. So I assume as you say for whatever reason something didn't copy over to the install location.

I used:

cmake \ 

	-DCMAKE_INSTALL_PREFIX="~/OpenFast/openfast/install" \

    	-DFPE_TRAP_ENABLED=ON \

    	-DBUILD_FAST_CPP_API:BOOL=ON \

    	-DBUILD_SHARED_LIBS:BOOL=ON \

    	../

flags when I installed.

Cheers
Callum

@rafmudaf
Copy link
Collaborator

rafmudaf commented Apr 2, 2020

This is a bug. With BUILD_SHARED_LIBS=ON, the expected install path of the shared libraries is not correct in the installation configuration in CMake. The libraries linked in aerodyn_driver and all other executables are not in the correct place since they are placed in lib and not bin.

>>mbp@~/Development/openfast/install/bin (feature/pyfast *$)$ otool -L aerodyn_driver 
aerodyn_driver:
	libaerodynlib.dylib (compatibility version 0.0.0, current version 0.0.0)
	libnwtclibs.dylib (compatibility version 0.0.0, current version 0.0.0)
	libversioninfolib.dylib (compatibility version 0.0.0, current version 0.0.0)
	/System/Library/Frameworks/Accelerate.framework/Versions/A/Accelerate (compatibility version 1.0.0, current version 4.0.0)
	/usr/local/opt/gcc@7/lib/gcc/7/libgfortran.4.dylib (compatibility version 5.0.0, current version 5.0.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1281.0.0)
	/usr/local/lib/gcc/7/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0)
	/usr/local/opt/gcc@7/lib/gcc/7/libquadmath.0.dylib (compatibility version 1.0.0, current version 1.0.0)

@sayerhs is the proper fix for this setting the RPATH of the executables?

@rafmudaf rafmudaf self-assigned this Apr 2, 2020
@rafmudaf rafmudaf changed the title [QUESTION] Running openfastcpp Binaries compiled with shared libraries are not properly installed Apr 2, 2020
@sayerhs
Copy link
Contributor

sayerhs commented Apr 2, 2020

@rafmudaf Short answer: yes, you should use RPATH so that the installed executable has shared library paths hard coded so that it will work without regard to the dynamic library lookup rules.

otool -L output is as expected for shared libraries, so that is not a bug but the correct behavior. The output doesn't mean that it is expecting to find libaerodynlib.dylib in install/bin, but are dynamically looked up based on OS specific rules. So you can set LD_LIBRARY_PATH in Linux and DYLD_LIBRARY_PATH in MacOS and have these executables work.

@rafmudaf rafmudaf mentioned this issue Mar 28, 2021
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@rafmudaf rafmudaf

Labels
System: CMake Type: Bug
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
5 participants
@sayerhs @andrew-platt @madsmammen @rafmudaf @CallumG-Ed