> -----Original Message-----
> From: dev <dev-boun...@dpdk.org> On Behalf Of Bruce Richardson
> Sent: Friday, June 26, 2020 8:30 PM
> To: dev@dpdk.org
> Cc: Richardson, Bruce <bruce.richard...@intel.com>
> Subject: [dpdk-dev] [PATCH] eal: don't use default library path for static
> binaries
>
> When using statically linked DPDK binaries, the EAL checks the default PMD
> path and tries to load any drivers there, despite the fact that all drivers
> are
> normally linked into the binary. This behaviour can cause issues if the PMD
> path and lib dir is configured to a non-standard location which is not in the
> ld.so.conf paths, e.g. a build with prefix set to a home directory location.
> In a
> case such as this, EAL will try and
> (unnecessarily) load the .so driver files but that load will fail as their
> dependent libraries, such as ethdev, for example, will not be found.
>
> Because of this, it is better if statically linked DPDK apps do not load
> drivers
> from the standard paths automatically. The user can always have this
> behaviour by explicitly specifying the path using -d flag, if so desired.
>
> Not loading the libraries automatically can also prevent potential issues
> with a
> user building and running a statically-linked DPDK binary based off a private
> copy of DPDK, while there exists on the same machine a system-wide
> installation of DPDK in the default locations. Without this change, the
> system-
> installed drivers will be loaded to the binary alongside the statically-linked
> drivers, which is not what the user would have intended.
>
> To detect whether we are in a statically or dynamically linked binary, we can
> have EAL try to get a dlopen handle to its own shared library, by calling
> dlopen with the RTLD_NOLOAD flag. This will return NULL if there is no such
> shared lib loaded i.e. the code is executing from a static library, or a
> handle to
> the lib if it is loaded.
>
> Signed-off-by: Bruce Richardson <bruce.richard...@intel.com>
> ---
> lib/librte_eal/common/eal_common_options.c | 11 +++++++++--
> 1 file changed, 9 insertions(+), 2 deletions(-)
>
> diff --git a/lib/librte_eal/common/eal_common_options.c
> b/lib/librte_eal/common/eal_common_options.c
> index 0901b493c..1d958d11e 100644
> --- a/lib/librte_eal/common/eal_common_options.c
> +++ b/lib/librte_eal/common/eal_common_options.c
> @@ -447,8 +447,15 @@ eal_plugins_init(void)
> struct shared_driver *solib = NULL;
> struct stat sb;
>
> - if (*default_solib_dir != '\0' && stat(default_solib_dir, &sb) == 0 &&
> - S_ISDIR(sb.st_mode))
> + /* if we are not statically linked, add default driver loading
> + * path if it exists as a directory.
> + * (Using dlopen with NOLOAD flag on eal, will return NULL if the eal
> + * shared library is not already loaded i.e. it's statically linked.)
> + */
> + if (dlopen("librte_eal.so", RTLD_LAZY | RTLD_NOLOAD) != NULL &&
> + *default_solib_dir != '\0' &&
> + stat(default_solib_dir, &sb) == 0 &&
> + S_ISDIR(sb.st_mode))
> eal_plugin_add(default_solib_dir);
>
> TAILQ_FOREACH(solib, &solib_list, next) {
> --
> 2.25.1
While trying to enable DPDK meson build for OVS , this patch turned out to be
quite beneficial when DPDK was installed using a prefix.
This fixes the "Cannot open shared object file: No such file or directory" seen
when OVS is built with static DPDK libraries.
Tested following scenarios with the patch and all of them function as expected:
1. system installed - OVS with DPDK static libs
2. system installed - OVS with DPDK shared libs
3. directory installed using the prefix - OVS with DPDK static libs
4. directory installed using the prefix - OVS with DPDK shared libs
OVS community would be grateful if this could be back ported to 19.11
Acked-by: Sunil Pai G <sunil.pa...@intel.com
