From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 01622A0520; Fri, 26 Jun 2020 19:05:53 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 6DDC21BEDD; Fri, 26 Jun 2020 19:05:53 +0200 (CEST) Received: from mail-pj1-f68.google.com (mail-pj1-f68.google.com [209.85.216.68]) by dpdk.org (Postfix) with ESMTP id 5BDC21BEC3 for ; Fri, 26 Jun 2020 19:05:52 +0200 (CEST) Received: by mail-pj1-f68.google.com with SMTP id f6so1181814pjq.5 for ; Fri, 26 Jun 2020 10:05:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=BC+Mmi+nigPhiF39wh1/UA7H7u39aK1dLE2LsLKG1mM=; b=lVeSOKN4WXV0VxIvnilO8nVhbGCxu0gy5RLLv0CrkllY4jKBAV/cW60d6rIefr0nwq QX9xkEl0EjMh1WWSSSI6s9HuCn4HyuPd5mOu0wug1shekzaAn4o4dZv/ImkWPlSKzRnl JLqfTxcCjhi0lGuj9yoLfRP3CXW4FcAHb7ZjKqXBKbiOUkucS3HSKulyJgy+Wwu/grSS hex1aWBr/GXRE4uNDO//1H3CJ/s1bfaoP5LkIEz5+Lf4XF6hOmUrGjOM+FB6l3rKKWvD wUZgKf32rKF5aLb5whPj/e+cle6jJOuvBPHb9+HKIrsbNkNBFaH/ieIrusmI6CqwByAg Ox/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=BC+Mmi+nigPhiF39wh1/UA7H7u39aK1dLE2LsLKG1mM=; b=K9LNyEBlJ4ZDV0Bkj9+lCEVsQwv4JcSajbj98D+nVAJnTov3lmYjUVbY1+UX1Cr94p sZGG+8CBcaN1ECZP9qfOnjhYhWxN1tX89rdqSSldYp8XFlZxaIFznN1vmPXVNyaBU21y YljMEYTIXJc8NtUMuF7yYLBroYXKlsSBJbVw7mTRp2ezR0ri3nNYGSsWI5wL6rPUv1ef BGMPzg9o2u85VugXybBWpm/Sw6ZBWPz09aBW9nmWAUs08nZwrJ5yS7ld38AM2zx9RUU5 y5aIsB2M8NjQ6hlax2aswKiaeYkocLAqhsU0KUPMsc2o6sIeCBZru4ck+jYN6Y4tP4+G 6Z6A== X-Gm-Message-State: AOAM530mLvC9zJ8+vmsk3k8TZRm9mqMCRbyTvT0wQkD+ZxCrRbZ8Jed8 6ykISa0S3qkG1ysmRpeOsrQOQQ== X-Google-Smtp-Source: ABdhPJwrHWVGbK7TApZh8b8RefvvoBlKhF852LQz6rYM8lWhzhOU+xhowsFNzoqpRYSdebhNs/5gvA== X-Received: by 2002:a17:902:b603:: with SMTP id b3mr3484343pls.1.1593191151364; Fri, 26 Jun 2020 10:05:51 -0700 (PDT) Received: from hermes.lan (204-195-22-127.wavecable.com. [204.195.22.127]) by smtp.gmail.com with ESMTPSA id z9sm18828188pgh.94.2020.06.26.10.05.50 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 26 Jun 2020 10:05:50 -0700 (PDT) Date: Fri, 26 Jun 2020 10:05:42 -0700 From: Stephen Hemminger To: Bruce Richardson Cc: dev@dpdk.org Message-ID: <20200626100542.1c87c2c9@hermes.lan> In-Reply-To: <20200626145957.722089-1-bruce.richardson@intel.com> References: <20200626145957.722089-1-bruce.richardson@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH] eal: don't use default library path for static binaries X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On Fri, 26 Jun 2020 15:59:57 +0100 Bruce Richardson wrote: > 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 But what if the majority of the DPDK is statically linked but the application wants also load a dynamically linked driver?