Re: Update to firebird 3.0 - install build

On 06/18/2016 03:37 PM, Lionel Elie Mamane wrote:
> So, in my opinion, a solution based on passing a full absolute path to
> --with-fb-plugins will not work in both situations. The effect of that
> is that the dlopen() call is to
> dlopen("/the/full/path/passed/to/with-fplugins/libEngine12.so", ...)
>
> No choice of full path will work in both situations.
>
> My best hunch, whose beginning was in the first part of my email of 2
> June with Message-Id <20160602191615.GA32068@capsaicin.mamane.lu>, but
> was not completely developed there, is to arrange for the dlopen()
> call to be just:
>
> dlopen("libEngine12.so", ...)
>
> Then dlopen() will do a search in various directories as documented in
> the manpage dlopen in section 3, and ld.so in section 8: rpath,
> LD_LIBRARY_PATH, runpath, /etc/ld.so.cache, the directories configured
> in /etc/ld.so.conf, ...
>
> Since we want to control the first directory searched, we will use the
> rpath, which is set at runtime. See e.g.
>
> $ objdump -p instdir/program/libfirebird_sdbclo.so|grep RPATH
>   RPATH                $ORIGIN
>
> "$ORIGIN" is a special value that is replaced at *runtime* by (dixit
> "man 8 ld.so") the directory containing the application executable.
>
> AFAIK, that's how LibreOffice itself finds its various subpieces, such
> as e.g. libfirebird_sdbclo.so, at least on Unix-like systems like
> e.g. GNU/Linux. Anybody on the mailing list can teach us what happens
> on Microsoft Windows and MacOS X?

In LO itself:

Link-time recording of dependencies on dynamic libraries is indeed done 
via RPATH on Linux (and via @executable_path/... or @loader_path/... 
relative paths on OS X, and mainly via "everything in one directory, and 
executables picking up dynamic libraries next to them" on Windows).

Dynamic loading of dynamic libraries (via the osl::Module abstraction; 
i.e., dlopen on Linux) is done with absolute paths computed at runtime 
(e.g., by passing macro'fied paths like "$BRAND_BASE_DIR/..." through 
rtl::Bootstrap::expandMacros, or by using osl::Module::loadRelative).