[dpdk-dev] [PATCH] eal: don't use default library path for static binaries

[Pai G, Sunil]

> -----Original Message-----
> From: dev <dev-bounces at dpdk.org> On Behalf Of Bruce Richardson
> Sent: Friday, June 26, 2020 8:30 PM
> To: dev at dpdk.org
> Cc: Richardson, Bruce <bruce.richardson at 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.richardson at 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.pai.g at intel.com