Any reason not add -fPIC to the OCPI_CXX_FLAGS environment variable?
The REDHAWK persona construct is a shared library that links to the programmable device executable. If OpenCPI has been installed with static libraries, we need fPIC to link to a dynamic library.
Sorry. The above occurred because I didn't take into account cflags
On a related note, since opencpi never really "installs" anywhere, should we update the environment scripts to update LD_LIBRARY_PATH with the location of the generated libraries?
static executables should not need fPIC to use dynamically loaded workers.
so you want to incorporate opencpi static libraries into a dynamic library?
that is a third case... static-for-dynamic.
Note that pic is a space and performance hit of as much as 10%.
As far as LD_LIBRARY_PATH goes, the current scheme makes it unnecessary if you are running on the system you build on, since the library paths are built into the executables using the rpath linker option. I think you can also use this when you are building shared libraries. Also, you can use $ORIGIN in the rpath to make things relative. So LD_LIBRARY_PATH is only really wanted if all of these are true.:
1. There is no relationship between where the "caller" binary is and the "callee" binary.
2. The "callee" library is not installed in a global place (/lib, /lib64, /usr/lib etc.)
3. The "callee" is built not knowing where the "caller" will be
Another trick is to have a package that has relative paths to symlinks at installation time.
Anyway, LD_LIBRARY_PATH is frequently problematic since multiple packages compete for position. Perhaps a concrete case?
I would put this entire thing low on your priority list, since it only became relevant when trying to build a general OpenCPI driver for REDHAWK programmable devices and personas, and since I'm still sort of working through possible solutions.
According to the persona instructions, a RH persona should be a shared object. However, I don't think that's true, it can probably be static. Regardless, when building a persona that is a shared object while trying to link to static ocpi libraries, the entire operation fails without fpic. I've also had some weirdness where libocpi_hdl does not define some lzma symbols when building statically against the static lzma library, which also causes the RH drivers not to build.
The LD_LIBRARY_PATH problem reared it's ugly head when trying to launch dynamically linked implementation of the RH-Ocpi drivers, since the runtime linker doesn't know where to look for the OCPI_LIB_DIR or the LZMA_LIB_DIR, even though I linked those with rpath as well.
Overall, I definitely have more work to do.
Ok my entire LD_LIBRARY_PATH fiasco was a typo in the makefile which has been resolved. I think this issue should be closed.