From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f53.google.com (mail-wm0-f53.google.com [74.125.82.53]) by dpdk.org (Postfix) with ESMTP id B4D6F374C for ; Thu, 30 Jun 2016 17:36:14 +0200 (CEST) Received: by mail-wm0-f53.google.com with SMTP id f126so227024744wma.1 for ; Thu, 30 Jun 2016 08:36:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:date:message-id:user-agent:in-reply-to :references:mime-version:content-transfer-encoding; bh=nQMhm6B5CdCAF9FW/ex7cOXNyKiXGa5E3tCkXvWmjdc=; b=am/HDOQfPaN1xx9eL9setMYPlUvBkmx8/2aUrWw7a6WeoMYZ/n1PmG9/TNqE4fyY3o WvfJCWOj2JGQ0Tyi9azf+lcAomxDaBRYrt9Gcs+6OJ+K/Ve5boispx/RrW1mrQTZbeEy zhlsOyCa6nJnH7ksiyjBD1qh74k0AXdQxjoREOmASamnbAms2NvOOOABLV/nkYGYJl4C XtnS6FPiFLAeC0Wi5F+zCthD4b0RhzUWpr4WtKEFU1aXus+aOU3lTMhKwcYckTy+npuc Snc/J6OkTwafoR5RSMGFeLCueBmOjIABNWUmKAjokE0opp4slBL54sgHvOMC4H7PcjgK LO3A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id:user-agent :in-reply-to:references:mime-version:content-transfer-encoding; bh=nQMhm6B5CdCAF9FW/ex7cOXNyKiXGa5E3tCkXvWmjdc=; b=Hy8QBEafCdg60Msb9d2GEHC1JJd4T82sn4dzw76bbZhv2r9XrNfwbuhVCLOuusgqcK ZMzmbgSfQA0AuGTL7JE1ah4mEVEm1/UreMDuAxfoL/AmkWx90rgjVrbZtvvsPuOqvZyp 1TJinSJsR/+Xo6lj/xHnmHXupZnAEbCwgB3du7dHid4P28GRM9Qkzy403lJProyltXTe wnhhLdzEj+1O40Z6ceYZlV1FKujdPeLPvGP6Y+v6GQoLMPAuNQmnQK2hNAWF5DK6XADH Db8MMKNNIQ/eZCVrN5ax6eOcBLi4sFdDMob6C+nKwC9eMG3xOI4QgUQB+O8yGF6xWEEz RirA== X-Gm-Message-State: ALyK8tIbS4PPCJvIgIOpcWlRpLoRWOhxVNlV4O9/OCh6/OhspcryUd2gL/qH96tUp/hcbLpH X-Received: by 10.28.26.67 with SMTP id a64mr26880551wma.70.1467300974457; Thu, 30 Jun 2016 08:36:14 -0700 (PDT) Received: from xps13.localnet (173.17.90.92.rev.sfr.net. [92.90.17.173]) by smtp.gmail.com with ESMTPSA id p76sm3503971wmd.10.2016.06.30.08.36.12 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 30 Jun 2016 08:36:13 -0700 (PDT) From: Thomas Monjalon To: Sergio Gonzalez Monroy Cc: dev@dpdk.org Date: Thu, 30 Jun 2016 17:28:27 +0200 Message-ID: <1797205.YMNToqyLHv@xps13> User-Agent: KMail/4.14.10 (Linux/4.5.4-1-ARCH; KDE/4.14.11; x86_64; ; ) In-Reply-To: <2994f200-70c4-3fe2-5976-fc1799271430@intel.com> References: <1467285021-103920-1-git-send-email-sergio.gonzalez.monroy@intel.com> <1776198.xo6Bm4C5fO@xps13> <2994f200-70c4-3fe2-5976-fc1799271430@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH] mk: fix acl library static linking X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2016 15:36:14 -0000 2016-06-30 15:02, Sergio Gonzalez Monroy: > On 30/06/2016 13:44, Thomas Monjalon wrote: > > 2016-06-30 13:04, Sergio Gonzalez Monroy: > >> On 30/06/2016 12:38, Thomas Monjalon wrote: > >>> Does it need to be commented in rte.app.mk? > >>> The other libs are in whole-archive to support dlopen of drivers. > >>> But the problem here is not because of a driver use. > >> There seem to be a bunch of libraries under --whole-archive scope that > >> are not > >> PMDs, ie. cfgfile, cmdline... > >> > >> What is the criteria? > > The criteria is a bit vague. We must try to include only libs which can > > be used by a driver. > > cmdline should probably not be there. > > Does it make sense to use cfgfile in a driver? maybe yes. > > So as it is, ACL autotest is broken when building static libs > (non-combined). I think the --whole-archive option must be set specifically for ACL with a comment explaining it is required because of weak functions: # librte_acl needs --whole-archive because of weak functions _LDLIBS-$(CONFIG_RTE_LIBRTE_ACL) += --whole-archive -lrte_acl --no-whole-archive > For combined libs we usually wrap libdpdk.a with --whole-archive, thus it is > not an issue. > > Just thinking a bit more about the 'dlopen of drivers' case you > mentioned before, > shouldn't the driver have proper dependencies and therefore need shared > DPDK libraries? It is possible to build a .so, without any DT_NEEDED entries, which will find the required symbols in the static linked binary. > What does happen if binary/app and driver are built against different > library versions? Bad things :) > Where does it say that we do support this use case? It is maybe not written. But I know it is used by people wanting to load some PMD.so on demand while having the rest statically compiled. I agree it needs to be documented and probably better managed and tested.